Re: Simple join optimized badly?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Craig A. James wrote:


My example, discussed previously in this forum, is a classic. I have a VERY expensive function (it's in the class of NP-complete problems, so there is no faster way to do it). There is no circumstance when my function should be used as a filter, and no circumstance when it should be done before a join. But PG has no way of knowing the cost of a function, and so the optimizer assigns the same cost to every function. Big disaster.

The result? I can't use my function in any WHERE clause that involves any other conditions or joins. Only by itself. PG will occasionally decide to use my function as a filter instead of doing the join or the other WHERE conditions first, and I'm dead.


this is an argument for cost-for-functions rather than hints AFAICS.

It seems to me that if (in addition to the function cost) we come up with some efficient way of recording cross column statistics we would be well on the way to silencing *most* of the demands for hints.

We would still be left with some of the really difficult problems - a metric for "locally correlated" column distributions and a reliable statistical algorithm for most common value sampling (or a different way of approaching this). These sound like interesting computer science or mathematics thesis topics, maybe we could try (again?) to get some interest at that level?

Cheers

Mark




[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux