Re: Performance issue in foreign-key-aware join estimation
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas.vondra@2ndquadrant.com>
Date: 2019-03-22T10:38:32Z
Lists: 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
Commits
-
Adjust overly strict Assert
- e1a0f6a98306 13.0 landed
-
Speed up finding EquivalenceClasses for a given set of rels
- 3373c7155350 13.0 landed
-
Speed up match_eclasses_to_foreign_key_col() when there are many ECs.
- fa86238f1eac 12.0 landed
- e22bfe94e4df 11.3 landed
- affee8b14c68 10.8 landed
- 09c9dd39efea 9.6.13 landed