David Rowley writes:
> On Fri, 20 Dec 2024 at 11:23, Tom Lane wrote:
>> Attached is a patch to take it out and then rename
>> BuildTupleHashTableExt() back to BuildTupleHashTable().
> No complaints here. Thanks for cleaning that up.
Thanks, will push.
> I couldn't help but also notice the nbuc
On Fri, 20 Dec 2024 at 11:23, Tom Lane wrote:
> Pushed ... and now I have one more beef about the way things are
> in this area. I don't think we should leave the compatibility
> function BuildTupleHashTable() in place in HEAD. Making it a
> wrapper around a new function BuildTupleHashTableExt()
Pushed ... and now I have one more beef about the way things are
in this area. I don't think we should leave the compatibility
function BuildTupleHashTable() in place in HEAD. Making it a
wrapper around a new function BuildTupleHashTableExt() was a fine
solution for preserving ABI in released bra
David Rowley writes:
> One minor detail... I think the only thing I'd like to see is the
> moving of the enable_hashagg checks to increment the disabled_nodes
> count in create_setop_path() instead of where it's being called. I
> understand there's only 1 caller of that function that passes
> SET
On Fri, 20 Dec 2024 at 08:38, Tom Lane wrote:
>
> David Rowley writes:
> > On Thu, 19 Dec 2024 at 15:44, Tom Lane wrote:
> >> The common_result_slot_type() function I wrote here perhaps
> >> should be made generally available, but I didn't do that yet.
>
> > I think it would be good to make this
David Rowley writes:
> On Thu, 19 Dec 2024 at 15:44, Tom Lane wrote:
>> The common_result_slot_type() function I wrote here perhaps
>> should be made generally available, but I didn't do that yet.
> I think it would be good to make this generic as it can be at least
> used in nodeRecursiveunion.
On Thu, 19 Dec 2024 at 15:44, Tom Lane wrote:
>
> With David's recent fixes to allow telling BuildTupleHashTableExt
> what input slot type to expect, it's possible to remove the per-row
> slot type conversions I was doing before. So here's an updated
> patchset with that done.
>
> The common_resu
With David's recent fixes to allow telling BuildTupleHashTableExt
what input slot type to expect, it's possible to remove the per-row
slot type conversions I was doing before. So here's an updated
patchset with that done.
The common_result_slot_type() function I wrote here perhaps
should be made
I wrote:
> So after digging into it, I realized that I'd been completely misled
> by setop_fill_hash_table's not failing while reading the first input.
> That's not because the code was correct, it was because none of our
> test cases manage to reach TupleHashTableMatch() while reading the
> first
I wrote:
> David Rowley writes:
>> nodeAgg.c seems to do this by using prepare_hash_slot() which deforms
>> the heap tuple and sets the Datums verbatim rather than making copies
>> of any byref ones.
> I'll take a look at that, thanks for the pointer.
So after digging into it, I realized that I'
David Rowley writes:
> Here's a quick review of all 5 patches together.
Thanks for looking at it!
> 1. In setop_load_group(), the primary concern with the result of
> setop_compare_slots() seems to be if the tuples match or not. If
> you're not too concerned with keeping the Assert checking for
On Wed, 20 Nov 2024 at 15:09, Tom Lane wrote:
> Once I'd wrapped my head around how things are done now (which the
> comments in prepunion.c were remarkably unhelpful about), I saw that
> most of the problem for #2 just requires re-ordering things that
> generate_nonunion_paths was already doing.
On Thu, 14 Nov 2024 at 22:33, Richard Guo wrote:
> BTW, I noticed a typo in the comment for function
> - * Returns false when sorted paths are not any more useful then unsorted
> + * Returns false when sorted paths are not any more useful than unsorted
I pushed a fix for that.
Thanks.
Richard Guo writes:
> On Thu, Nov 14, 2024 at 11:00 AM Tom Lane wrote:
>> Aside from that minor TODO, the main thing that's left undone in this
>> patch series is to persuade the thing to exploit presorted input
>> paths.
> I think we may need to do the following to make this work:
> 1. We need
On Thu, Nov 14, 2024 at 6:28 PM Richard Guo wrote:
> 1. We need to teach set_operation_ordered_results_useful() that sorted
> input paths are also useful for INTERSECT/EXCEPT, so that we can have
> setop_pathkeys set for the subqueries.
BTW, I noticed a typo in the comment for function
set_operat
On Thu, Nov 14, 2024 at 11:00 AM Tom Lane wrote:
> Aside from that minor TODO, the main thing that's left undone in this
> patch series is to persuade the thing to exploit presorted input
> paths. Right now it fails to do so, as can be seen in some of the
> regression test cases, eg
>
> regressio
Here are the beginnings of a patchset to do what was discussed at [1],
namely change the SetOp node type to read its inputs as outerPlan and
innerPlan, rather than appending them together with a flag column to
show which rows came from where.
The previous thread wondered why manually DISTINCT'ing
17 matches
Mail list logo
