Neil Conway <[EMAIL PROTECTED]> writes:
> It occurred to me that these kinds of poor planning decisions could easily
> be detected by PostgreSQL itself: after we've finished executing a plan, we
> can trivially compare the # of results produced by each node in the query
> tree with the # of results the planner expected that node to produce
There's a dual to this as well. If the results were very close but the actual
time taken to run the node doesn't match the cost calculated then some
optimizer parameter needs to be adjusted. Either one of the cost_* parameters
or random_page_cost, or effective_cache_size or...
I'm not sure it's as obvious what to put in the HINT though. Ideally these
results would have to be gathered and pumped through linear optimization
algorithms which is a lot more work.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
