Greg Smith wrote: > On 06/14/2011 01:16 PM, Robert Haas wrote: > > But there's no reason that code (which may or may not eventually prove > > useful) has to be incorporated into the main tree. We don't commit > > code so people can go benchmark it; we ask for the benchmarking to be > > done first, and then if the results are favorable, we commit the code. > > > > Who said anything about this being a commit candidate? The "WIP" in the > subject says it's not intended to be. The community asks people to > submit design ideas early so that ideas around them can be explored > publicly. One of the things that needs to be explored, and that could > use some community feedback, is exactly how this should be benchmarked > in the first place. This topic--planning based on cached > percentage--keeps coming up, but hasn't gone very far as an abstract > discussion. Having a patch to test lets it turn to a concrete one. > > Note that I already listed myself as the reviewer here, so it's not > even like this is asking explicitly for a community volunteer to help. > Would you like us to research this privately and then dump a giant patch > that is commit candidate quality on everyone six months from now, > without anyone else getting input to the process, or would you like the > work to happen here? I recommended C?dric not ever bother soliciting > ideas early, because I didn't want to get into this sort of debate. I > avoid sending anything here unless I already have a strong idea about > the solution, because it's hard to keep criticism at bay even with > that. He was more optimistic about working within the community > contribution guidelines and decided to send this over early instead. If > you feel this is too rough to even discuss, I'll mark it returned with > feedback and we'll go develop this ourselves.
I would like to see us continue researching in this direction. I think perhaps the background writer would be ideal for collecting this information because it scans the buffer cache already, and frequently. (Yes, I know it can't access databases.) I think random_page_cost is a dead-end --- it will never be possible for it to produce the right value for us. Its value is tied up in caching, e.g. the default 4 is not the right value for a physical drive (it should be much higher), but kernel and shared buffer caching require it to be a hybrid number that isn't really realistic. And once we have caching in that number, it is not going to be even caching for all tables, obviously. Hence, there is no way for random_page_cost to be improved and we have to start thinking about alternatives. Basically, random_page_cost is a terrible setting and we have to admit that and move forward. I realize the concerns about unstable plans, and we might need to give users the option of stable plans with a fixed random_page_cost, but at this point we don't even have enough data to know we need that. What we do know is that random_page_cost is inadequate. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
