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-09T00:18:57Z
Lists: pgsql-hackers
On Sat, 9 Mar 2019 at 08:05, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Setting the CF entry to WOA for now. I wonder though if we should > just push it out to v13 immediately --- are you intending to do more > with it in the near future? Thanks a lot for going over this and providing feedback. I put the patch out there mostly to see if such a thing is something we might want, and it's good to see no objections to the idea. I didn't want to waste too much time if there was going to be some serious objections to the idea. This is something I'd like to look into for v13. I think it'll be much easier to do if we can get your List reimplementation patch in first. That's going to allow list_nth on PlannerInfo->eq_classes to work quickly and will remove the need for having to build an array to store the classes, and as you mention, RelOptInfo could store a Bitmapset to store which ECs have members for this rel. I've modified the CF entry to target v13. -- 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