Re: Creating foreign key on partitioned table is too slow - Mailing list pgsql-hackers

From David Rowley
Subject Re: Creating foreign key on partitioned table is too slow
Date
Msg-id CAKJS1f9qtvaWwK2NXvPit8q1gAy3FjMU=bFME_71ka8ztjcGxQ@mail.gmail.com
Whole thread Raw
In response to Re: Creating foreign key on partitioned table is too slow  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 31 Oct 2019 at 17:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <david.rowley@2ndquadrant.com> writes:
> > In Ottawa this year, Andres and I briefly talked about the possibility
> > of making a series of changes to how equalfuncs.c works. The idea was
> > to make it easy by using some pre-processor magic to allow us to
> > create another version of equalfuncs which would let us have an equal
> > comparison function that returns -1 / 0 / +1 rather than just true or
> > false.  This would allow us to Binary Search Trees of objects. I
> > identified that EquivalenceClass.ec_members would be better written as
> > a BST to allow much faster lookups in get_eclass_for_sort_expr().
>
> This seems like a good idea, but why would we want to maintain two
> versions?  Just change equalfuncs.c into comparefuncs.c, full stop.
> equal() would be a trivial wrapper for (compare_objects(a,b) == 0).

If we can do that without slowing down the comparison, then sure.
Checking which node sorts earlier is a bit more expensive than just
checking for equality. But if that's not going to be noticeable in
real-world test cases, then I agree.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Ibrar Ahmed
Date:
Subject: Re: fe-utils - share query cancellation code
Next
From: Andrew Dunstan
Date:
Subject: Allow superuser to grant passwordless connection rights onpostgres_fdw