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-16 07:24:46 |
Message-ID: | KGEFLMPJFBNNLNOOOPLGKEPACHAA.simon@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>Josh Berkus
> > 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.
>
> Well, there is ... all of the various query cost parameters.
They are very blunt instruments for such a delicate task.
Surely someone of your experience might have benefit from something
more?
My feeling is, I would, though I want those tools as *a developer*
rather than for tuning specific queries for people, which is always so
sensitive to upgrades etc.
> But, ultimately, improvements on the planner are still
> bottlenecked by having
> only one developer actually hacking the changes.
>
Do we have a clear list of optimizations we'd like to be working on?
The TODO items aren't very related to specific optimizations...
The only ones I was aware of was deferred subselect evaluation for
DBT-3.
...sounds like there's more to discuss here, so I'll duck out now and
get back to my current project...
Best Regards, Simon Riggs
From | Date | Subject | |
---|---|---|---|
Next Message | Rajesh Kumar Mallah | 2004-04-16 08:23:50 | Re: [ SOLVED ] select count(*) very slow on an already |
Previous Message | Greg Stark | 2004-04-16 02:27:20 | Re: PostgreSQL and Linux 2.6 kernel. |