Re: PostgreSQL and Linux 2.6 kernel.

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: PostgreSQL and Linux 2.6 kernel.
Date: 2004-04-14 20:12:18
Message-ID: KGEFLMPJFBNNLNOOOPLGIEOBCHAA.simon@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> Josh Berkus wrote:
> Unfortunately, these days only Tom and Neil seem to be
> seriously working on
> the query planner (beg pardon in advance if I've missed
> someone) so I think
> the real answer is that we need another person interested in
> this kind of
> optimization before it's going to get much better.
>

Hmmmm. Interesting line of thought.

Is the problem "a person interested" or is there another issue there?

I was thinking the other day that maybe removing the ability to control
join order through explicitly manipulating the FROM clause might
actually be counter productive, in terms of longer term improvement of
the optimizer.

Treating the optimizer as a black box is something I'm very used to from
other RDBMS. My question is, how can you explicitly re-write a query now
to "improve" it? If there's no way of manipulating queries without
actually re-writing the optimizer, we're now in a position where we
aren't able to diagnose when the optimizer isn't working effectively.

For my mind, all the people on this list are potential "optimizer
developers" in the sense that we can all look at queries and see whether
there is a problem with particular join plans. Providing good cases of
poor optimization is just what's needed to assist those few that do
understand the internals to continue improving things.

I guess what I'm saying is it's not how many people you've got working
on the optimizer, its how many accurate field reports of less-than
perfect optimization reach them. In that case, PostgreSQL is likely in a
better position than Microsoft, since the accessibility of the pg
discussion lists makes such cases much more likely to get aired.

Any thoughts?

Best Regards, Simon Riggs

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Rajesh Kumar Mallah 2004-04-14 20:43:03 Re: select count(*) very slow on an already vacuumed table.
Previous Message Richard Huxton 2004-04-14 19:08:58 Re: select count(*) very slow on an already vacuumed table.