On Sun, Feb 27, 2011 at 3:03 AM, Bruce Momjian <bruce(at)momjian(dot)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.
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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2011-02-27 18:44:32|
|Subject: pgsql: Refactor the executor's API to support data-modifying CTEsbette|
|Previous:||From: Robert Haas||Date: 2011-02-27 17:24:43|
|Subject: Re: WIP: cross column correlation ...|