Jim Nasby wrote:
> On 2/14/17 3:13 AM, Seki, Eiji wrote:
> > +extern TransactionId GetOldestXmin(Relation rel, uint8
> > ignoreFlags);
>
> My impression is that most other places that do this sort of thing just call
> the argument 'flags', so as not to "lock in" a single idea of what the flags
On 14.02.2017 16:59, Jim Nasby wrote:
On 2/13/17 10:45 AM, Konstantin Knizhnik wrote:
It is not true - please notice query execution time of this two queries:
I bet you'd get even less difference if you simply cast to float8
instead of adding 0.0. Same result, no floating point addition.
Hi, I tried regression test and found some errors concerning brin and gin,
though I didn't look into this.
Here's a log:
*** /home/ideriha/postgres-master/src/test/regress/expected/brin.out
2017-02-13 11:33:43.270942937 +0900
--- /home/ideriha/postgres-master/src/test/regress/results/brin.out
On 14 February 2017 at 22:24, David Fetter wrote:
> On Mon, Feb 13, 2017 at 05:31:56PM +0530, Amit Khandekar wrote:
>> Currently, an update of a partition key of a partition is not
>> allowed, since it requires to move the row(s) into the applicable
>> partition.
>>
>> Attached is a WIP patch (upd
On 14 February 2017 at 22:35, Robert Haas wrote:
> On Mon, Feb 6, 2017 at 12:36 AM, Amit Khandekar
> wrote:
>>> Now that I think of that, I think for implementing above, we need to
>>> keep track of per-subplan max_workers in the Append path; and with
>>> that, the bitmap will be redundant. Inst
On Fri, Feb 10, 2017 at 3:19 PM, Amit Langote
wrote:
> The new partitioned tables do not contain any data by themselves. Any
> data inserted into a partitioned table is routed to and stored in one of
> its partitions. In fact, it is impossible to insert *any* data before a
> partition (to be pre
Amit Kapila wrote:
> How will you decide just based on oldest xmin whether the tuple is visible or
> not? How will you take decisions about tuples which have xmax set?
In our use case, GetOldestXmin is used by an original maintainer process[es] to
an original control table[s]. The table can be
On Wed, Feb 15, 2017 at 11:08 AM, Robert Haas wrote:
> I think the patch as presented probably isn't quite what we want,
> because it waits synchronously for the second result to be ready.
> Note that the wait for the first result is asynchronous: we check
> PQisBusy and return without progressing
On Wed, Feb 15, 2017 at 4:38 AM, Robert Haas wrote:
> On Tue, Feb 14, 2017 at 4:24 AM, Amit Kapila wrote:
>> On further evaluation, it seems this patch has one big problem which
>> is that it will allow forming parallel plans which can't be supported
>> with current infrastructure. For ex. marki
On Tue, Feb 14, 2017 at 09:24:47PM -0800, Joshua Chamberlain wrote:
> Hello,
>
> (I'm posting to hackers since I got no response on the general
> list.)
>
> I use Postgres + PostGIS quite heavily, and recently have been
> taking full advantage of the new parallelism in 9.6. I'm now running
> quer
On Tue, Feb 14, 2017 at 1:13 AM, Fujii Masao wrote:
> On Mon, Feb 13, 2017 at 4:05 PM, Masahiko Sawada
> wrote:
>> On Sat, Feb 11, 2017 at 8:18 PM, Petr Jelinek
>> wrote:
>>> On 10/02/17 19:55, Masahiko Sawada wrote:
On Thu, Feb 9, 2017 at 12:44 AM, Petr Jelinek
wrote:
> On 08/02
Andres Freund writes:
> I don't quite see the point of this - there's a lot of settings that cause
> spurious test failures. I don't see any point fixing random cases of that.
> And I don't think the continual cost of doing so overall is worth the minimal
> gain.
> What's your reason to get t
On Wed, Feb 15, 2017 at 2:24 PM, Joshua Chamberlain wrote:
> Are there plans in 10.0 to allow parallelism in queries that write, or at
> least in "CREATE TABLE AS" queries? (Support in materialized views would be
> great, too!)
Nope. There are no patches for now.
--
Michael
--
Sent via pgsql-
Hello,
(I'm posting to hackers since I got no response on the general list.)
I use Postgres + PostGIS quite heavily, and recently have been taking full
advantage of the new parallelism in 9.6. I'm now running queries in a few
hours that would otherwise take more than a day.
However, parallelism
On February 14, 2017 9:02:14 PM PST, neha khatri wrote:
>On Wed, Feb 15, 2017 at 10:04 AM, neha khatri
> wrote:.
>>
>>
>>> Attached are two options for doing that. One overrides bytea_output
>>> locally where-ever needed, and the other overrides it for the entire
>>> 'regression' database.
>>>
On Wed, Feb 15, 2017 at 10:04 AM, neha khatri
wrote:.
>
>
>> Attached are two options for doing that. One overrides bytea_output
>> locally where-ever needed, and the other overrides it for the entire
>> 'regression' database.
>>
>
> The solution that overrides bytea_output locally looks appropr
On Wed, Feb 15, 2017 at 3:18 AM, Jim Nasby wrote:
> Why not do what we do for pg_stat_activity.current_query and leave it NULL
> for non-SU?
If subcriptions are designed to be superuser-only, it seems fair to me
to do so. Some other system SRFs do that already.
> Even better would be if we coul
Jeff Janes writes:
> make installcheck fails against a server running with
> operator_precedence_warning = on.
> The difference is in update.out, and consists of an error-locating carat
> getting moved over by one position. I've attached the regression diff.
> I don't know why the setting of th
Robert Haas writes:
> Well put. Although it's worth noting that we aren't 100% consistent
> about this stuff: sum(smallint), sum(integer), and sum(bigint) all use
> an output data type different from the input data type, but other
> versions of sum() don't.
In those cases I believe the main reas
On Wed, Feb 15, 2017 at 4:46 AM, Robert Haas wrote:
> On Mon, Feb 13, 2017 at 11:07 PM, Amit Kapila wrote:
>> I have removed the check of AlternativeSubPlan so that it can be
>> handled by expression_tree_walker.
> ...
>> Attached patch fixes all the comments raised till now.
>
> Committed after
On Wed, Feb 15, 2017 at 2:38 AM, Robert Haas wrote:
> On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier
> wrote:
>> In short, I'd like to think that we should just filter out those two
>> parameters by name and call it a day. Or introduce an idea of value
>> set for the environment by adding some k
On Mon, Feb 13, 2017 at 5:57 AM, Amit Langote
wrote:
> On 2017/02/13 14:21, Amit Langote wrote:
>> On 2017/02/10 19:19, Simon Riggs wrote:
>>> * The OID inheritance needs work - you shouldn't need to specify a
>>> partition needs OIDS if the parent has it already.
>>
>> That sounds right. It's be
On Wed, Feb 8, 2017 at 9:36 PM, Amit Kapila wrote:
> On Tue, Feb 7, 2017 at 11:47 AM, Haribabu Kommi
> wrote:
> > Hi Hackers,
> >
> > I just want to discuss adding of a new statistics view that provides
> > the information of wal writing details as follows
> >
>
> +1. I think it will be useful
On Fri, Feb 10, 2017 at 3:00 AM, Simon Riggs wrote:
> Given that we already have partitioning feature committed, we really
> need to have the docs committed as well.
Just for the record, it's not like there were no documentation changes
in the originally committed patch. In fact there were over
On Tue, Feb 14, 2017 at 8:59 AM, Jim Nasby wrote:
>> From my point of your it is strange and wrong expectation.
>> I am choosing "float4" type for a column just because it is enough to
>> represent range of data I have and I need to minimize size of record.
>
> In other words, you've decided to tr
make installcheck fails against a server running with
operator_precedence_warning
= on.
The difference is in update.out, and consists of an error-locating carat
getting moved over by one position. I've attached the regression diff.
I don't know why the setting of this GUC causes the carat to mov
On Wed, Feb 15, 2017 at 2:22 PM, Tom Lane wrote:
> Adding a C.F.I. inside this loop is the most straightforward fix, but
> I am leaning towards adding one in ExecHashJoinGetSavedTuple instead,
> because that would also ensure that all successful paths through
> ExecHashJoinOuterGetTuple will do a
On Wed, Feb 15, 2017 at 11:08 AM, Robert Haas wrote:
> On Tue, Feb 14, 2017 at 7:12 PM, Tom Lane wrote:
>> FWIW, my own habit when creating new PG files is generally to write
>>
>> * Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
>> * Portions Copyright (c) 1994, Regents
On Tue, Feb 14, 2017 at 7:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 14, 2017 at 5:16 PM, Michael Paquier
>> wrote:
>>> Just for curiosity: does the moment when the code has been written or
>>> committed counts? It's no big deal seeing how liberal the Postgres
>>> license is, bu
On Tue, Feb 14, 2017 at 12:11 AM, Michael Paquier
wrote:
> On Thu, Feb 2, 2017 at 3:01 PM, Higuchi, Daisuke
> wrote:
>> From: Michael Paquier [mailto:michael.paqu...@gmail.com]
>>>This has not been added yet to the next CF. As Ashutosh mentioned
>>>things tend to be easily forgotten. So I have ad
I ran into a case where a hash join took a really long time to respond
to a cancel request --- long enough that I gave up and kill -9'd it,
because its memory usage was also growing to the point where the kernel
would likely soon choose to do that for me. The culprit seems to be
that there's no CH
Robert Haas writes:
> On Tue, Feb 14, 2017 at 5:16 PM, Michael Paquier
> wrote:
>> Just for curiosity: does the moment when the code has been written or
>> committed counts? It's no big deal seeing how liberal the Postgres
>> license is, but this makes me wonder...
> IANAL, but I think if you as
On Wed, Feb 15, 2017 at 2:08 AM, Robert Haas wrote:
> On Mon, Feb 13, 2017 at 5:00 PM, Michael Paquier
> wrote:
>> It seems like the previous review I provided for the set of renaming
>> patches has been ignored:
>> https://www.postgresql.org/message-id/CAB7nPqSm=PNSe3EfvnEResdFzpQMcXXgapFBcF=EFd
On Mon, Feb 13, 2017 at 10:34 PM, Tom Lane wrote:
> Jim Nasby writes:
>> Is there a reason not to allow $SUBJECT? Specifically, it'd be nice to
>> be able to do something like WHEN tag LIKE 'ALTER%'.
>
> Seems like it would be a seriously bad idea for such an expression to be
> able to invoke arb
Hi all,
I propose a new feature for high availability.
This configuration is effective for following configuration:
1. Primary and synchronous standby are in the same center; called main center.
2. Asynchronous standby is in the another center; called backup center.
(The backup center is l
On Tue, Feb 14, 2017 at 5:16 PM, Michael Paquier
wrote:
> On Wed, Feb 15, 2017 at 2:43 AM, Robert Haas wrote:
>> On Thu, Feb 9, 2017 at 8:17 PM, Michael Paquier
>> wrote:
>>> Please find attached a patch with those fixes.
>>
>> Committed, but I changed the copyright dates to 2016-2017 rather tha
On Tue, Feb 14, 2017 at 4:06 PM, Alvaro Herrera
wrote:
> I'd rather have a --quiet mode instead. If you're running it by hand,
> you're likely to omit the switch, whereas when writing the cron job
> you're going to notice lack of switch even before you let the job run
> once.
Well, that might've
On Mon, Feb 13, 2017 at 11:07 PM, Amit Kapila wrote:
> I have removed the check of AlternativeSubPlan so that it can be
> handled by expression_tree_walker.
...
> Attached patch fixes all the comments raised till now.
Committed after removing the reference to AlternativeSubPlan from the
comment.
On 2017-02-14 17:58:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-11-26 08:41:28 -0800, Andres Freund wrote:
> >> On November 26, 2016 8:06:26 AM PST, Tom Lane wrote:
> >>> Those don't call functions, they call operators. Yes, I know that an
> >>> operator has a function underlyi
On Tue, Feb 14, 2017 at 4:24 AM, Amit Kapila wrote:
> On further evaluation, it seems this patch has one big problem which
> is that it will allow forming parallel plans which can't be supported
> with current infrastructure. For ex. marking immediate level params
> as parallel safe can generate
On Wed, Feb 15, 2017 at 8:50 AM, Jeff Janes wrote:
> make installcheck currently fails against a server running
> with bytea_output = escape.
>
> Making it succeed is fairly easy, and I think it is worth doing.
>
> Attached are two options for doing that. One overrides bytea_output
> locally whe
Hello Tom,
So moving the conditional stack back into PsqlScanState has some side
effects: conditional.[ch] have to move to the fe_utils/ dirs, and now
pgbench, which does not use conditionals, would have to link to them. Is
that a small price to pay for modularity and easier-to-find code? Or sh
On Tue, Feb 14, 2017 at 4:44 PM, Tom Lane wrote:
> Corey Huinker writes:
> > So moving the conditional stack back into PsqlScanState has some side
> > effects: conditional.[ch] have to move to the fe_utils/ dirs, and now
> > pgbench, which does not use conditionals, would have to link to them. I
Andres Freund writes:
> On 2016-11-26 08:41:28 -0800, Andres Freund wrote:
>> On November 26, 2016 8:06:26 AM PST, Tom Lane wrote:
>>> Those don't call functions, they call operators. Yes, I know that an
>>> operator has a function underlying it, but the user-level expectation
>>> for track_func
On 2016-11-26 08:41:28 -0800, Andres Freund wrote:
> On November 26, 2016 8:06:26 AM PST, Tom Lane wrote:
> >Robert Haas writes:
> >> On Fri, Nov 25, 2016 at 11:12 PM, Andres Freund
> >wrote:
> >>> while working on my faster expression evaluation stuff I noticed
> >that a
> >>> lot of expression
On Wed, Feb 15, 2017 at 2:43 AM, Robert Haas wrote:
> On Thu, Feb 9, 2017 at 8:17 PM, Michael Paquier
> wrote:
>> Please find attached a patch with those fixes.
>
> Committed, but I changed the copyright dates to 2016-2017 rather than
> just 2017 since surely some of the code was originally writt
On Wed, Feb 15, 2017 at 3:55 AM, Jeff Janes wrote:
> I thought people would object to checking the version number in two
> different places to make the same fundamental decision, and would want that
> refactored somehow. But if you are OK with it, then I am.
The binary versions are checked only
On Wed, Feb 15, 2017 at 2:44 AM, Robert Haas wrote:
> I committed the patch posted to the other thread. Hopefully that
> closes this issue.
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
make installcheck currently fails against a server running
with bytea_output = escape.
Making it succeed is fairly easy, and I think it is worth doing.
Attached are two options for doing that. One overrides bytea_output
locally where-ever needed, and the other overrides it for the entire
'regres
Corey Huinker writes:
> So moving the conditional stack back into PsqlScanState has some side
> effects: conditional.[ch] have to move to the fe_utils/ dirs, and now
> pgbench, which does not use conditionals, would have to link to them. Is
> that a small price to pay for modularity and easier-to-
Robert Haas wrote:
> On Tue, Feb 14, 2017 at 12:06 PM, Magnus Hagander wrote:
> > However, outputing this info by default will make it show up in things like
> > everybodys cronjobs by default. Right now a successful pg_basebackup run
> > will come out with no output at all, which is how most Unix
Jim Nasby writes:
> On 2/14/17 1:18 PM, Tom Lane wrote:
>> One point that could use further review is whether the de-duplication
>> algorithm is actually correct. I'm only about 95% convinced by the
>> argument I wrote in planunionor.c's header comment.
> I'll put some thought into it and see if
Robert Haas wrote:
> On Tue, Feb 14, 2017 at 2:54 PM, Andres Freund wrote:
> >> Thoughts, comments, objections, better ideas?
> >
> > No better ideas. I'm a bit concerned about declarations needed both by
> > normal and xlog related routines, but I guess that can be solved by a
> > third header a
Dne 14. 2. 2017 21:35 napsal uživatel "Andres Freund" :
On 2017-02-14 14:29:56 -0600, Jim Nasby wrote:
> On 2/14/17 1:59 PM, Andres Freund wrote:
> > > AFAIK if you're doing make check (as opposed to installcheck) it's
> > > significantly more complicated than that since you'd have to create a
tem
On Tue, Feb 14, 2017 at 2:54 PM, Andres Freund wrote:
>> Thoughts, comments, objections, better ideas?
>
> No better ideas. I'm a bit concerned about declarations needed both by
> normal and xlog related routines, but I guess that can be solved by a
> third header as you did.
Yeah, that doesn't
On 2/14/17 1:18 PM, Tom Lane wrote:
I think this might be code-complete, modulo the question of whether we
want an enabling GUC for it. I'm still concerned about the question
of whether it adds more planning time than it's worth for most users.
(Obviously it needs some regression test cases too,
On 15 February 2017 at 03:41, Robert Haas wrote:
> On Tue, Feb 14, 2017 at 5:17 AM, David Rowley
> wrote:
>> Updated patch attached.
>
> Committed and back-patched to 9.6.
Great. Thanks Robert.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
On 2017-02-14 12:19:56 -0800, Josh Berkus wrote:
> On 02/14/2017 12:05 PM, Tom Lane wrote:
> > Jim Nasby writes:
> >> First, just to clarify: my reasons for proposing "core adoption" of PGXN
> >> are not technical in nature.
> >
> > What do you think "core adoption" means? Surely not that anyth
On 2017-02-14 14:29:56 -0600, Jim Nasby wrote:
> On 2/14/17 1:59 PM, Andres Freund wrote:
> > > AFAIK if you're doing make check (as opposed to installcheck) it's
> > > significantly more complicated than that since you'd have to create a temp
> > > cluster/install yourself.
> >
> > But in that cas
On 2/14/17 2:19 PM, Josh Berkus wrote:
One part of this would need to be having a designated committee of the
Postgres community pick a set of "blessed" extensions for packagers to
package. Right now, contrib serves that purpose (badly). One of the
reasons we haven't dealt with the extension di
On Tue, Feb 14, 2017 at 12:48 PM, Robert Haas wrote:
> That sounds way better.
Here's an updated patch. Please review my changes, which include:
* Various comment updates.
* _bt_parallel_seize now unconditionally sets *pageno to P_NONE at the
beginning, instead of doing it conditionally at the
On 2/14/17 1:59 PM, Andres Freund wrote:
AFAIK if you're doing make check (as opposed to installcheck) it's
significantly more complicated than that since you'd have to create a temp
cluster/install yourself.
>
But in that case you can't have useful templates in the regression test
either, so t
On 02/14/2017 12:05 PM, Tom Lane wrote:
> Jim Nasby writes:
>> First, just to clarify: my reasons for proposing "core adoption" of PGXN
>> are not technical in nature.
>
> What do you think "core adoption" means? Surely not that anything
> associated with PGXN would be in the core distro.
One
On 2/14/17 2:05 PM, Tom Lane wrote:
Jim Nasby writes:
First, just to clarify: my reasons for proposing "core adoption" of PGXN
are not technical in nature.
What do you think "core adoption" means? Surely not that anything
associated with PGXN would be in the core distro.
No, certainly not.
Jim Nasby writes:
> First, just to clarify: my reasons for proposing "core adoption" of PGXN
> are not technical in nature.
What do you think "core adoption" means? Surely not that anything
associated with PGXN would be in the core distro.
> Right now contrib is serving two completely separate
On 2017-02-14 12:33:35 -0600, Jim Nasby wrote:
> On 2/13/17 8:50 PM, Andres Freund wrote:
> > On 2017-02-14 11:46:52 +0900, Michael Paquier wrote:
> > > > I still fail to see why --use-existing as suggested in
> > > > https://www.postgresql.org/message-id/20170208002900.vkldujzfkwbvq...@alap3.anara
Hi,
On 2017-02-13 22:42:00 -0500, Robert Haas wrote:
> I dug into the problem and discovered that pg_waldump is slurping up a
> tremendous crapload of backend headers. It includes gin.h,
> gist_private.h, hash_xlog.h, nbtree.h, and spgist.h, which all end up
> including amapi.h, which includes ge
First, just to clarify: my reasons for proposing "core adoption" of PGXN
are not technical in nature. My desire is to have an extension/add-on
system that's officially endorsed and embraced by the official
community, similar to CPAN, pypy, npm, etc. There's no technical reason
we need PGXN to b
I wrote:
> The main remaining piece of work here is that, as you can see from the
> above, it fails to eliminate joins to tables that we don't actually need
> in a particular UNION arm. This is because the references to those
> tables' ctid columns prevent analyzejoins.c from removing the joins.
>
On 02/14/2017 03:22 AM, Andres Freund wrote:
Hi,
On 2017-02-11 14:40:18 +0100, Tomas Vondra wrote:
On 02/11/2017 02:33 AM, Andres Freund wrote:
I have a hard time believing this the cache efficiency of linked lists
(which may or may not be real in this case) out-weights this, but if you
want t
On Mon, Feb 13, 2017 at 6:19 PM, Michael Paquier
wrote:
> On Tue, Feb 14, 2017 at 9:09 AM, Jeff Janes wrote:
> > check for "/usr/local/pgsql9_6/bin/pg_resetwal" failed: No such file or
> > directory
> >
> > This looks somewhat complicated to fix. Should check_bin_dir test the
> old
> > cluster
On Tue, Feb 14, 2017 at 12:06 PM, Magnus Hagander wrote:
> However, outputing this info by default will make it show up in things like
> everybodys cronjobs by default. Right now a successful pg_basebackup run
> will come out with no output at all, which is how most Unix commands work,
> and bring
On 2/14/17 3:13 AM, Seki, Eiji wrote:
+extern TransactionId GetOldestXmin(Relation rel, uint8 ignoreFlags);
My impression is that most other places that do this sort of thing just
call the argument 'flags', so as not to "lock in" a single idea of what
the flags are for. I can't readily thin
On 2/13/17 8:50 PM, Andres Freund wrote:
On 2017-02-14 11:46:52 +0900, Michael Paquier wrote:
I still fail to see why --use-existing as suggested in
https://www.postgresql.org/message-id/20170208002900.vkldujzfkwbvq...@alap3.anarazel.de
isn't sufficient.
Some tests create objects without remov
On Mon, Feb 13, 2017 at 3:40 PM, Fabien COELHO wrote:
> What would be the mnemonic for "," an "@"?
Oh, I just picked it because control-@ is the nul character, and your
commands would be nullified. I realize that's pretty weak, but we're
talking about finding a punctuation mark to represent the
On 2/13/17 11:12 AM, Robert Haas wrote:
FWIW, this is a significant problem outside of DDL. Once you're past 1-2
levels of nesting SET client_min_messages = DEBUG becomes completely
useless.
I think the ability to filter logging based on context would be very
valuable. AFAIK you could actually d
On 2/13/17 9:36 PM, Michael Paquier wrote:
Probably I failed to get Peter's point... Anyway IMO that we can expose all the
columns except the sensitive information (i.e., subconninfo field)
in pg_subscription to even non-superusers. Then we can use pg_subscription
for the tab-completion for ALTER
After seeing Yet Another Missing Psql Tab Completion it occurred to
me... why not add a checklist item to the commitfest review page? I
realize most regular contributors don't use the form, but a fair number
of people do. I don't see how it could hurt.
Another possible idea is a git hook that
On 2/13/17 9:34 PM, Tom Lane wrote:
Jim Nasby writes:
Is there a reason not to allow $SUBJECT? Specifically, it'd be nice to
be able to do something like WHEN tag LIKE 'ALTER%'.
Seems like it would be a seriously bad idea for such an expression to be
able to invoke arbitrary SQL code. What i
On Feb 14, 2017, at 9:37 AM, Magnus Hagander wrote:
> It's a failing in one of the two at least. It either needs to be easier to
> build the things on windows, or pgxn would need to learn to do binary
> distributions.
PGXN makes no effort to support installation on any platform at all. Happy
On Mon, Feb 13, 2017 at 9:04 PM, Amit Kapila wrote:
> I think the comment at that place is not as clear as it should be. So
> how about changing it as below:
>
> Existing comment:
> --
> /*
> * For parallel scans, get the last page scanned as it is quite
> * possible that
On Mon, Feb 13, 2017 at 8:00 PM, Michael Paquier
wrote:
> Beginning a new thread to raise awareness... As already reported here,
> I had a look at what has been committed in a507b869:
> https://www.postgresql.org/message-id/CAB7nPqRzCQb=vdfhvmtp0hmlbhu6z1agdo4gjsup-hp8jx+...@mail.gmail.com
>
> Her
On Thu, Feb 9, 2017 at 8:17 PM, Michael Paquier
wrote:
> Please find attached a patch with those fixes.
Committed, but I changed the copyright dates to 2016-2017 rather than
just 2017 since surely some of the code was originally written before
2017. Even that might not really be going back far e
On Fri, Feb 10, 2017 at 12:54 AM, Amit Langote
wrote:
> On 2017/02/09 15:22, amul sul wrote:
>> About 0001-Check-partition-strategy-in-ATExecDropNotNull.patch,
>> following test is already covered in alter_table.sql @ Line # 1918,
>> instead of this kindly add test for list_partition:
>>
>> 77 +-
On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier
wrote:
> On Thu, Feb 9, 2017 at 8:17 PM, Amit Kapila wrote:
>> +1. Sounds sensible thing to do.
>
> Hm. It seems to me that PGPASSFILE still needs to be treated as an
> exception because it is set to $HOME/.pgpass without any value set in
> PQconni
On Feb 14, 2017 18:26, "David E. Wheeler" wrote:
On Feb 14, 2017, at 5:37 AM, Jim Nasby wrote:
>> Until pgxn has a way of helping users on for example Windows (or other
>> platforms where they don't have a pgxs system and a compiler around),
>> it's always going to be a "second class citizen".
On Mon, Feb 13, 2017 at 2:30 AM, Amit Langote
wrote:
> I noticed that running ALTER TABLE table_name DETACH PARTITION crashes, if
> table_name is not a partitioned table. That's because of an Assert in
> ATExecDetachPartition(). We really should error out much sooner in this
> case, IOW during
On Sun, Jul 17, 2016 at 7:15 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> On Sun, Jul 17, 2016 at 12:22 AM, Jun Cheol Gim wrote:
>>> If we have timestamp of first and last executed, we can easily gather thess
>>> informations and there are tons of more use cases.
>
>> -1 from me.
>
>> I thin
On Feb 14, 2017, at 5:37 AM, Jim Nasby wrote:
>> Until pgxn has a way of helping users on for example Windows (or other
>> platforms where they don't have a pgxs system and a compiler around),
>> it's always going to be a "second class citizen".
>
> I view that as more of a failing of pgxs than
On Mon, Feb 13, 2017 at 11:38 PM, Stephen Frost wrote:
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Mon, Feb 13, 2017 at 2:42 PM, Alvaro Herrera
> > wrote:
> > > Well, we can remove them from PG10 and pgAdmin3 (and others) be
> adjusted
> > > to use the new ones, conditionally on serv
On Mon, Feb 13, 2017 at 5:00 PM, Michael Paquier
wrote:
> It seems like the previous review I provided for the set of renaming
> patches has been ignored:
> https://www.postgresql.org/message-id/CAB7nPqSm=PNSe3EfvnEResdFzpQMcXXgapFBcF=EFdxVW4=f...@mail.gmail.com
> Good that somebody else checked..
On Mon, Feb 13, 2017 at 10:33 AM, Michael Banck
wrote:
> Hi,
>
> Am Montag, den 13.02.2017, 09:31 +0100 schrieb Magnus Hagander:
> > On Mon, Feb 13, 2017 at 3:29 AM, Jim Nasby
> > wrote:
> > On 2/11/17 4:36 AM, Michael Banck wrote:
> > I guess you're right, I've moved it
On Tue, Feb 14, 2017 at 12:05 PM, Robert Haas wrote:
> Having the extra
> 1-2 workers exist does not seem better.
Err, exit, not exist.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Mon, Feb 6, 2017 at 12:36 AM, Amit Khandekar wrote:
>> Now that I think of that, I think for implementing above, we need to
>> keep track of per-subplan max_workers in the Append path; and with
>> that, the bitmap will be redundant. Instead, it can be replaced with
>> max_workers. Let me check
On Mon, Feb 13, 2017 at 05:31:56PM +0530, Amit Khandekar wrote:
> Currently, an update of a partition key of a partition is not
> allowed, since it requires to move the row(s) into the applicable
> partition.
>
> Attached is a WIP patch (update-partition-key.patch) that removes
> this restriction.
On Fri, Feb 10, 2017 at 10:36 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 12/31/16 11:43 AM, Tom Lane wrote:
> > Magnus Hagander writes:
> >> I still think that some wording in the direction of the fact that the
> >> majority of all users won't actually have this problem
On Tue, Feb 14, 2017 at 12:18 AM, Dilip Kumar wrote:
> Fixed.
Thanks, the external interface to this looks much cleaner now.
Scrutinizing the internals:
What is the point of having a TBMSharedIterator contain a TIDBitmap
pointer? All the values in that TIDBitmap are populated from the
TBMShared
On Mon, Feb 13, 2017 at 7:01 AM, Amit Khandekar wrote:
> partspartitioned inheritance no. of rows subpartitions
> ==== === === =
>
> 500 10 sec 3 min 02 sec 1,000,000 0
> 1000 10 sec 3 min 05 sec 1,000,000
On Tue, Feb 14, 2017 at 5:17 AM, David Rowley
wrote:
> On 14 February 2017 at 21:25, Amit Kapila wrote:
>> +Aggregate stage. For such cases there is clearly going to be no
>> +performance benefit to using parallel aggregation.
>>
>> A comma is required after "For such cases"
>
> Added
>
>
On Tue, Feb 14, 2017 at 8:37 AM, Jim Nasby wrote:
> Right; I think we need at least some amount of pgxn buildfarm coverage.
> There probably also needs to be a way to officially bless certain
> distributions. Unless there's a pretty significant need for an official
> extension to be in contrib, it
1 - 100 of 127 matches
Mail list logo
