Re: PostgreSQL and Linux 2.6 kernel. - Mailing list pgsql-performance

From Simon Riggs
Subject Re: PostgreSQL and Linux 2.6 kernel.
Date
Msg-id KGEFLMPJFBNNLNOOOPLGIEOBCHAA.simon@2ndquadrant.com
Whole thread Raw
In response to Re: PostgreSQL and Linux 2.6 kernel.  (Josh Berkus <josh@agliodbs.com>)
Responses Re: PostgreSQL and Linux 2.6 kernel.
Re: PostgreSQL and Linux 2.6 kernel.
List 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


pgsql-performance by date:

Previous
From: Richard Huxton
Date:
Subject: Re: select count(*) very slow on an already vacuumed table.
Next
From: Rajesh Kumar Mallah
Date:
Subject: Re: select count(*) very slow on an already vacuumed table.