On 06/14/2011 11:04 AM, Robert Haas wrote:
> Even if the data were accurate and did not cause plan stability, we
> have no evidence that using it will improve real-world performance.
>
That's the dependency Cédric has provided us a way to finally make
progress on. Everyone says there's no evidence that this whole approach
will improve performance. But we can't collect such data, to prove or
disprove it helps, without a proof of concept patch that implements
*something*. You may not like the particular way the data is collected
here, but it's a working implementation that may be useful for some
people. I'll take "data collected at ANALYZE time" as a completely
reasonable way to populate the new structures with realistic enough test
data to use initially.
Surely at least one other way to populate the statistics, and possibly
multiple other ways that the user selects, will be needed eventually. I
commented a while ago on this thread: every one of these discussions
always gets dragged into the details of how the cache statistics data
will be collected and rejects whatever is suggested as not good enough.
Until that stops, no progress will ever get made on the higher level
details. By its nature, developing toward integrating cached
percentages is going to lurch forward on both "collecting the cache
data" and "using the cache knowledge in queries" fronts almost
independently. This is not a commit candidate; it's the first useful
proof of concept step for something we keep talking about but never
really doing.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
