Re: Thinking About Correlated Columns (again)
От | Andrew Dunstan |
---|---|
Тема | Re: Thinking About Correlated Columns (again) |
Дата | |
Msg-id | 5193BA52.7040007@dunslane.net обсуждение исходный текст |
Ответ на | Re: Thinking About Correlated Columns (again) (Craig James <cjames@emolecules.com>) |
Список | pgsql-performance |
On 05/15/2013 12:23 PM, Craig James wrote: > On Wed, May 15, 2013 at 8:31 AM, Shaun Thomas > <sthomas@optionshouse.com <mailto:sthomas@optionshouse.com>> wrote: > > [Inefficient plans for correlated columns] has been a pain point > for quite a while. While we've had several discussions in the > area, it always seems to just kinda trail off and eventually > vanish every time it comes up. > > ... > Since there really is no fix for this aside from completely > rewriting the query or horribly misusing CTEs (to force sequence > scans instead of bloated nested loops, for example)... > I'm worried that without an easy answer for cases like this, more > DBAs will abuse optimization fences to get what they want and > we'll end up in a scenario that's actually worse than query hints. > Theoretically, query hints can be deprecated or have GUCs to > remove their influence, but CTEs are forever, or until the next > code refactor. > > I've seen conversations on this since at least 2005. There were > even proposed patches every once in a while, but never any > consensus. Anyone care to comment? > > > It's a very hard problem. There's no way you can keep statistics > about all possible correlations since the number of possibilities is > O(N^2) with the number of columns. > I don't see why we couldn't allow the DBA to specify some small subset of the combinations of columns for which correlation stats would be needed. I suspect in most cases no more than a handful for any given table would be required. cheers andrew
В списке pgsql-performance по дате отправления: