Re: Limiting the number of parameterized indexpaths created
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2012-10-31T19:58:52Z
Lists: pgsql-hackers
On 31 October 2012 19:44, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Before 9.2, we didn't have this problem in this guise because we didn't > generate parameterized paths bottom-up; instead, given that we had > already decided to join t2 and t3 for some reason, we would look to see > what indexpaths we could make for t1 using values from t2 and/or t3. > However, that approach had big problems of its own: it couldn't find > plans that involved pushing parameters down through an intervening join. Given that most joins patterns are repeated consistently across multiple SQL statements, is it possible to pre-calculate paths at ANALYZE time, or perhaps cache them (persistently?) when first generated? That way we just look up best paths, which would make join planning much faster. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rethink heuristics for choosing index quals for parameterized paths.
- 3b8968f25232 9.3.0 cited