From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jesper(dot)pedersen(at)redhat(dot)com |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, sulamul(at)gmail(dot)com, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Subject: | Re: COLLATE: Hash partition vs UPDATE |
Date: | 2019-04-14 20:50:07 |
Message-ID: | 30551.1555275007@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> writes:
> Yeah, that works here - apart from an issue with the test case; fixed in
> the attached.
Couple issues spotted in an eyeball review of that:
* There is code that supposes that partsupfunc[] is the last
field of ColumnsHashData, eg
fcinfo->flinfo->fn_extra =
MemoryContextAllocZero(fcinfo->flinfo->fn_mcxt,
offsetof(ColumnsHashData, partsupfunc) +
sizeof(FmgrInfo) * nargs);
I'm a bit surprised that this patch manages to run without crashing,
because this would certainly not allocate space for partcollid[].
I think we would likely be well advised to do
- FmgrInfo partsupfunc[PARTITION_MAX_KEYS];
+ FmgrInfo partsupfunc[FLEXIBLE_ARRAY_MEMBER];
to make it more obvious that that has to be the last field. Or else
drop the cuteness with variable-size allocations of ColumnsHashData.
FmgrInfo is only 48 bytes, I'm not really sure that it's worth the
risk of bugs to "optimize" this.
* I see collation-less calls of the partsupfunc at both partbounds.c:2931
and partbounds.c:2970, but this patch touches only the first one. How
can that be right?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-04-14 23:25:14 | Re: partitioning performance tests after recent patches |
Previous Message | Jeff Janes | 2019-04-14 20:47:09 | Re: Should the docs have a warning about pg_stat_reset()? |