> "Andrew" == Andrew Gierth writes:
Andrew> My inclination is to fix this in the planner rather than the
Andrew> executor; there seems no good reason to actually hash a
Andrew> duplicate column more than once.
I take this back; I don't believe it's possible to eliminate duplicates
in all
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> My inclination is to fix this in the planner rather than the
>> executor; there seems no good reason to actually hash a duplicate
>> column more than once.
Tom> Sounds reasonable --- but would it make sense to introduce some
Tom>
Andrew Gierth writes:
> My inclination is to fix this in the planner rather than the executor;
> there seems no good reason to actually hash a duplicate column more than
> once.
Sounds reasonable --- but would it make sense to introduce some
assertions, or other cheap tests, into the executor to
> "Andrew" == Andrew Gierth writes:
>>> Attached is a patch for a write after allocated memory which we
>>> found in testing. Its an obscure case but can happen if the same
>>> column is used in different grouping keys, as in the example below,
>>> which uses tables from the regress test
> "Tom" == Tom Lane writes:
>> Attached is a patch for a write after allocated memory which we
>> found in testing. Its an obscure case but can happen if the same
>> column is used in different grouping keys, as in the example below,
>> which uses tables from the regress test suite (build
Colm McHugh writes:
> Attached is a patch for a write after allocated memory which we found in
> testing. Its an obscure case but can happen if the same column is used in
> different grouping keys, as in the example below, which uses tables from
> the regress test suite (build with --enable-casser
