On Sat, Jun 25, 2016 at 12:44 AM, Robert Haas wrote:
> On Wed, Jun 22, 2016 at 4:11 AM, Amit Langote
> wrote:
> >> In an outer join we have to differentiate between a row being null
> (because
> >> there was no joining row on nullable side) and a non-null row with all
> >> column values being nu
On Mon, Jun 27, 2016 at 10:21 AM, Amit Kapila wrote:
> On Sun, Jun 26, 2016 at 3:57 PM, Julien Rouhaud
> wrote:
>> On 26/06/2016 08:37, Amit Kapila wrote:
>>>
>>> @@ -370,6 +379,8 @@ ForgetBackgroundWorker(slist_mutable_iter *cur)
>>> Assert(rw->rw_shmem_slot <
>>> max_worker_processes);
>>>
On Sun, Jun 26, 2016 at 3:57 PM, Julien Rouhaud
wrote:
> On 26/06/2016 08:37, Amit Kapila wrote:
>>
>> @@ -370,6 +379,8 @@ ForgetBackgroundWorker(slist_mutable_iter *cur)
>> Assert(rw->rw_shmem_slot <
>> max_worker_processes);
>> slot = &BackgroundWorkerData->slot[rw->rw_shmem_slot];
>> slot
In general, moving tuplesort.c batch memory caller tuples around
happens when batch memory needs to be recycled, or freed outright with
pfree().
I failed to take into account that CLUSTER tuplesorts need an extra
step when moving caller tuples to a new location (i.e. when moving
HeapTuple caller t
On Sun, Jun 19, 2016 at 05:56:12PM +0900, Michael Paquier wrote:
> The new pg_stat_wal_receiver does not include primary_conninfo.
> Looking at that now, it looks almost stupid not to include it...
> Adding it now would require a catalog bump, so I am not sure if this
> is acceptable at this stage
On Mon, Jun 13, 2016 at 05:27:13PM -0400, Robert Haas wrote:
> One problem that I've realized that is related to this is that the way
> that the consider_parallel flag is being set for upper rels is almost
> totally bogus, which I believe accounts for your complaint at PGCon
> that force_parallel_m
On Mon, Jun 13, 2016 at 04:46:19PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > In practice, we don't yet have the ability for
> > parallel-safe paths from subqueries to affect planning at higher query
> > levels, but that's because the pathification stuff landed too late in
> > the cycle for
On Mon, Jun 13, 2016 at 03:42:49PM -0400, Tom Lane wrote:
> I wrote:
> > ... there was also an unexplainable plan change:
>
> > *** /home/postgres/pgsql/src/test/regress/expected/aggregates.out Thu Apr
> > 7 21:13:14 2016
> > --- /home/postgres/pgsql/src/test/regress/results/aggregates.out
On Wed, Jun 15, 2016 at 11:08:54AM -0400, Noah Misch wrote:
> On Wed, Jun 15, 2016 at 03:02:15PM +0300, Teodor Sigaev wrote:
> > On Wed, Jun 15, 2016 at 02:54:33AM -0400, Noah Misch wrote:
> > > On Mon, Jun 13, 2016 at 10:44:06PM -0400, Noah Misch wrote:
> > > > On Fri, Jun 10, 2016 at 03:10:40AM -
On Thu, Jun 23, 2016 at 10:57:26AM -0400, Tom Lane wrote:
> David Rowley writes:
> > On 23 June 2016 at 11:22, Tom Lane wrote:
> >> The behavior that I'd expect (and that I documented) for a deserialization
> >> function is that it just allocates its result in the current, short-lived
> >> memory
On 27 June 2016 at 03:36, Tom Lane wrote:
> After having worked on the patch some, I think that AggSplit is a pretty
> good choice, because it is about how we split up the calculation of an
> aggregate. And it's short, which is a good thing for something that's
> going to be a component of assort
On Tue, Jun 21, 2016 at 10:59:25AM +1200, Thomas Munro wrote:
> On Fri, Jun 17, 2016 at 3:36 PM, Noah Misch wrote:
> > I agree the non-atomic, unlogged change is a problem. A related threat
> > doesn't require a torn page:
> >
> > AssignTransactionId() xid=123
> > heapam.c:3931 HeapTupleHeade
On 27 June 2016 at 08:28, Tom Lane wrote:
> David Rowley writes:
>> On 27 June 2016 at 03:36, Tom Lane wrote:
>>> Looking at this in the light of morning, I'm rather strongly tempted to
>>> invert the sense of the FINALIZE option, so that "simple" mode works out
>>> as zero, ie, select no option
On Mon, Jun 13, 2016 at 9:39 AM, Robert Haas wrote:
> There is no realistic way that I am going to have this fixed before
> beta2. There are currently 10 open items listed on the open items
> page, of which 8 relate to my commits and 5 to parallel query in
> particular. I am not going to get 8 i
I wrote:
> [ shrug... ] I do not buy that argument, because it doesn't justify
> the COMBINE option: why shouldn't that be inverted, ie USEFINALFUNC?
Sorry, I meant USETRANSFUNC of course.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
David Rowley writes:
> On 27 June 2016 at 03:36, Tom Lane wrote:
>> Looking at this in the light of morning, I'm rather strongly tempted to
>> invert the sense of the FINALIZE option, so that "simple" mode works out
>> as zero, ie, select no options. Maybe call it SKIPFINAL instead of
>> FINALIZ
I noticed that the EXPLAIN code is set up so that in non-text output
modes, you get output like this for partial-aggregate plans:
"Node Type": "Aggregate", +
"Strategy": "Plain", +
"Operation": "Finalize", +
...
On 27 June 2016 at 03:36, Tom Lane wrote:
> Looking at this in the light of morning, I'm rather strongly tempted to
> invert the sense of the FINALIZE option, so that "simple" mode works out
> as zero, ie, select no options. Maybe call it SKIPFINAL instead of
> FINALIZE?
Aggref calls this aggpar
Andrey Zhidenkov writes:
> It's very strange, but when I use expression 'update test set test =
> 'test' where id = 1' as argument of plpy.execute() memory do not
> growing at all...
Well, that suggests it's not particularly plpython's fault at all, but
a leak somewhere in the table update. You
It's very strange, but when I use expression 'update test set test =
'test' where id = 1' as argument of plpy.execute() memory do not
growing at all...
On Sun, Jun 26, 2016 at 9:05 PM, Andrey Zhidenkov
wrote:
> Thank you for your answer, Tom.
>
> I've tried code in your example and I still see an
Thank you for your answer, Tom.
I've tried code in your example and I still see an always growing
memory consumption (1Mb per second). As it was before, I do not see
growing memory if
I use 'select 1' query as argument of plpy.execute(). Table test does
not has any triggers or foreign keys, I just
David Rowley writes:
> On 26 June 2016 at 04:07, Tom Lane wrote:
>> After a bit of thought, maybe AggDivision or AggSplit or something
>> along those lines?
> How about AggCompletion? It's seems to fit well in the sense of the
> aggregation being partial or not, but less well when you consider
>
On 26/06/2016 08:37, Amit Kapila wrote:
> On Sat, Jun 25, 2016 at 2:27 PM, Julien Rouhaud
> wrote:
>>>
>>
>> It's better thanks. Should we document somewhere the link between this
>> parameter and custom dynamic background workers or is it pretty
>> self-explanatory?
>>
>
> How about if add an a
On 2016-05-16 21:40, Piotr Stefaniak wrote:
Hello,
while investigating the shm_mq code and its testing module I made some
cosmetic improvements there. You can see them in the attached diff file.
Revised patch attached.
commit 3ff1afa84e4bc22f153c876e2f0588327a8a004e
Author: Piotr Stefaniak
D
On 2016-05-27 08:13, Piotr Stefaniak wrote:
I'm trying to see if FreeBSD indent can successfully do pg_bsd_indent's
job. So far I had to fix one thing, which is not adding a space after a
cast operator, for which they added no option to turn it off. Currently
I'm fighting one other bug, but I thi
25 matches
Mail list logo
