Hi,
On 2020-03-23 13:29:02 -0700, Jeff Davis wrote:
> On Sat, 2020-03-21 at 18:26 -0700, Andres Freund wrote:
> > I don't see how? That'd require making the hash bucket addressing
> > deal
> > with variable sizes, which'd be bad for performance reasons. Since
> > there
> > can be a aggstate->numtr
On Sat, 2020-03-21 at 18:26 -0700, Andres Freund wrote:
> I don't see how? That'd require making the hash bucket addressing
> deal
> with variable sizes, which'd be bad for performance reasons. Since
> there
> can be a aggstate->numtrans AggStatePerGroupDatas for each hash table
> entry, I don't se
Hi,
On 2020-03-21 17:45:31 -0700, Jeff Davis wrote:
> Or, we can keep the 'additionalsize' argument but put it to work store
> the AggStatePerGroupData inline in the hash table. That would allow us
> to remove the 'additional' pointer from TupleHashEntryData, saving 8
> bytes plus the chunk header
On Fri, 2020-03-13 at 00:34 +, Andrew Gierth wrote:
> > > > > > "Justin" == Justin Pryzby writes:
>
> > On Thu, Mar 12, 2020 at 12:16:26PM -0700, Andres Freund wrote:
> >> Indeed, that's incorrect. Causes the number of buckets for the
> >> hashtable to be set higher - the size is just used
Thanks, Andres Freund and Andres Gierth.
To be related, can I invite you to help to review the parallel grouping sets
patches? It will be very great to hear some comments from you since you
contributed most of the codes for grouping sets.
the thread is
https://www.postgresql.org/message-id/CAG4re
On Fri, Mar 13, 2020 at 8:34 AM Andrew Gierth
wrote:
> > "Justin" == Justin Pryzby writes:
>
> > On Thu, Mar 12, 2020 at 12:16:26PM -0700, Andres Freund wrote:
> >> Indeed, that's incorrect. Causes the number of buckets for the
> >> hashtable to be set higher - the size is just used for t
>
> On 2020-03-12 16:35:15 +0800, Pengzhou Tang wrote:
> > When reading the grouping sets codes, I find that the additional size of
> > the hash table for hash aggregates is always zero, this seems to be
> > incorrect to me, attached a patch to fix it, please help to check.
>
> Indeed, that's incor
Hi,
On 2020-03-13 00:34:22 +, Andrew Gierth wrote:
> > "Justin" == Justin Pryzby writes:
>
> > On Thu, Mar 12, 2020 at 12:16:26PM -0700, Andres Freund wrote:
> >> Indeed, that's incorrect. Causes the number of buckets for the
> >> hashtable to be set higher - the size is just used for
> "Justin" == Justin Pryzby writes:
> On Thu, Mar 12, 2020 at 12:16:26PM -0700, Andres Freund wrote:
>> Indeed, that's incorrect. Causes the number of buckets for the
>> hashtable to be set higher - the size is just used for that. I'm a
>> bit wary of changing this in the stable branches
On Thu, Mar 12, 2020 at 12:16:26PM -0700, Andres Freund wrote:
> On 2020-03-12 16:35:15 +0800, Pengzhou Tang wrote:
> > When reading the grouping sets codes, I find that the additional size of
> > the hash table for hash aggregates is always zero, this seems to be
> > incorrect to me, attached a pa
Hi,
On 2020-03-12 16:35:15 +0800, Pengzhou Tang wrote:
> When reading the grouping sets codes, I find that the additional size of
> the hash table for hash aggregates is always zero, this seems to be
> incorrect to me, attached a patch to fix it, please help to check.
Indeed, that's incorrect. C
Hi hacker,
When reading the grouping sets codes, I find that the additional size of
the hash table for hash aggregates is always zero, this seems to be
incorrect to me, attached a patch to fix it, please help to check.
Thanks,
Pengzhou
0001-Set-numtrans-correctly-when-building-hash-aggregate-.p
12 matches
Mail list logo
