Re: PostgreSQL and Linux 2.6 kernel.
От | Simon Riggs |
---|---|
Тема | Re: PostgreSQL and Linux 2.6 kernel. |
Дата | |
Msg-id | KGEFLMPJFBNNLNOOOPLGKEPACHAA.simon@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL and Linux 2.6 kernel. (Josh Berkus <josh@agliodbs.com>) |
Список | 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
В списке pgsql-performance по дате отправления: