Re: [HACKERS] Better solution to final adjustment of combining Aggrefs

I wrote: > The patch is not quite finished: as noted in the XXX comment, it'd be > a good idea to refactor apply_partialaggref_adjustment so that it can > share code with this function, to ensure they produce identical > representations of the lower partial Aggref. But that will just make > the

Re: [HACKERS] Rethinking representation of partial-aggregate steps

I wrote: > David Rowley writes: >> The attached implements this, with the exception that I didn't really >> think AggPartialMode was the best name for the enum. I've named this >> AggregateMode instead, as the aggregate is only partial in some cases. > Hm. We

Re: [HACKERS] Bug in to_timestamp().

On Fri, Jun 24, 2016 at 3:43 PM, Joshua D. Drake wrote: > On 06/24/2016 02:16 PM, Tom Lane wrote: > >> Robert Haas writes: >> >>> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford >>> wrote: >>> To me,

Re: [HACKERS] Rethinking representation of partial-aggregate steps

David Rowley writes: > The attached implements this, with the exception that I didn't really > think AggPartialMode was the best name for the enum. I've named this > AggregateMode instead, as the aggregate is only partial in some cases. Hm. We already have an

[HACKERS] Better solution to final adjustment of combining Aggrefs

I complained earlier about the brute-force way that the partial aggregation patch deals with constructing Aggrefs for the upper stage of aggregation. It copied-and-pasted several hundred lines of setrefs.c so as to inject a nonstandard rule for comparing upper and lower Aggrefs. That's bulky and

Re: [HACKERS] Rename max_parallel_degree?

On Wed, Jun 15, 2016 at 11:43 PM, Julien Rouhaud wrote: > > Attached v4 implements the design you suggested, I hope everything's ok. > Few review comments: 1. + if (parallel && (BackgroundWorkerData->parallel_register_count - +

Re: [HACKERS] Memory leak in Pl/Python

I found commit, that fixes some memory leaks in 9.6 beta 2: https://github.com/postgres/postgres/commit/8c75ad436f75fc629b61f601ba884c8f9313c9af#diff-4d0cb76412a1c4ee5d9c7f76ee489507 I'm interesting in how Tom Lane check that is no more leaks in plpython? On Sat, Jun 25, 2016 at 4:54 AM, Andrey

Re: [HACKERS] bug in citext's upgrade script for parallel aggregates

On 06/24/2016 01:31 PM, David Rowley wrote: Seems there's a small error in the upgrade script for citext for 1.1 to 1.2 which will cause min(citext) not to be parallel enabled. max(citext)'s combinefunc is first set incorrectly, but then updated to the correct value. I assume it was meant to

Re: [HACKERS] Rename max_parallel_degree?

On 25/06/2016 09:33, Amit Kapila wrote: > On Wed, Jun 15, 2016 at 11:43 PM, Julien Rouhaud > wrote: >> >> Attached v4 implements the design you suggested, I hope everything's ok. >> > > Few review comments: > Thanks for the review. > 1. > + if (parallel &&

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

Craig Ringer writes: > On 24 June 2016 at 21:34, Tom Lane wrote: >> TBH, this looks more like a compiler bug than anything else. > I tend to agree. Especially since valgrind has no complaints on x64 linux, > and neither does DrMemory for 32-bit builds

Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

"Haroon ." writes: > And if I comment these out i.e. setup_description, setup_privileges and > 'setup_schema' it seem to progress well without any errors/crashes. Presumably, what you've done there is remove every single join query from the post-bootstrap scripts.

Re: [HACKERS] Memory leak in Pl/Python

Andrey Zhidenkov writes: > I see memory consumption in htop and pg_activity tools. "top" can be pretty misleading if you don't know how to interpret its output, specifically that you have to discount whatever it shows as SHR space. That just represents the amount of