Multi-pass planner - Mailing list pgsql-hackers

From decibel
Subject Multi-pass planner
Date
Msg-id AD81F44E-0BBE-4335-9CBC-1C8A6A7E81D4@decibel.org
Whole thread Raw
Responses Re: Multi-pass planner  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
There have been a number of planner improvement ideas that have been  
thrown out because of the overhead they would add to the planning  
process, specifically for queries that would otherwise be quiet fast.  
Other databases seem to have dealt with this by creating plan caches  
(which might be worth doing for Postgres), but what if we could  
determine when we need a fast planning time vs when it won't matter?

What I'm thinking is that on the first pass through the planner, we  
only estimate things that we can do quickly. If the plan that falls  
out of that is below a certain cost/row threshold, we just run with  
that plan. If not, we go back and do a more detailed estimate.
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828




pgsql-hackers by date:

Previous
From: Ygor Degani
Date:
Subject: Duplicated Keys in PITR
Next
From: Ygor Degani
Date:
Subject: Duplicated Keys in PITR