Re: Performance issue in foreign-key-aware join estimation - Mailing list pgsql-hackers

From David Rowley
Subject Re: Performance issue in foreign-key-aware join estimation
Date
Msg-id CAKJS1f-KgonusPcWctDjTCWkw4dAxa98VP6YVr9uFwukGf2X4w@mail.gmail.com
Whole thread Raw
In response to Re: Performance issue in foreign-key-aware join estimation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Performance issue in foreign-key-aware join estimation
List pgsql-hackers
Thanks for having a hack at this.

On Fri, 22 Mar 2019 at 10:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm unsure how hard we should push to get something like this into v12.
> I'm concerned that its dependency on list_nth might result in performance
> regressions in some cases; it's a lot easier to believe that this will
> be mostly-a-win with the better List infrastructure we're hoping to get
> into v13.  If you want to keep playing with it, OK, but I'm kind of
> tempted to shelve it for now.

Yeah,  mentioned a similar concern above.  The best I could come up
with to combat it was the list_skip_forward function. It wasn't
particularly pretty and was only intended as a stop-gap until List
become array-based. I think it should stop any regression.  I'm okay
with waiting until we get array based Lists, if you think that's best,
but it's a bit sad to leave this regression in yet another major
release.

However, there's always a danger we find some show-stopper with your
list reimplementation patch, in which case I wouldn't really like to
be left with list_skip_forward() in core.

If there's any consensus we want this for v12, then I'll happily look
over your patch, otherwise, I'll look sometime before July.

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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: GiST VACUUM
Next
From: Michael Paquier
Date:
Subject: Re: Offline enabling/disabling of data checksums