On Sun, Feb 27, 2011 at 3:03 AM, Bruce Momjian <br...@momjian.us> wrote: >> You make it sound as if we know how but are just too lazy to right the >> code. That is not one of the weaknesses that this community has. > > Well, several automatic idea have been floated, but rejected because > they don't work well for queries that are planned and executed later. > Perhaps we should consider auto-tuning of queries that are planned for > immediate execution. I just posed that idea in an email to this thread.
Which ideas were rejected for that reason? If we're talking about the idea of using the current contents of the buffer cache and perhaps the OS cache to plan queries, I think that's not likely to work well even if we do restrict it to queries that we're going to execute immediately. Upthread I listed four problems with the idea of planning queries based on the current contents of shared_buffers, and this certainly doesn't address all four. http://archives.postgresql.org/pgsql-hackers/2011-02/msg02206.php To reiterate my basic theme here one more time, we have a very good query planner, but it can fall on its face very badly when it is unable to correctly estimate selectivity, or due to caching effects, and we have very little to recommend to people who run afoul of those problems right now. The problems are real, significant, and affect a large number of users, some of whom give up on PostgreSQL as a direct result. I am glad that we are committed to having a system that is auto-tuning to the greatest degree possible, but I think it is very short-sighted of us not to provide workarounds for the cases where they are legitimately needed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
