Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,
pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>,
Boszormenyi Zoltan <zb(at)cybertec(dot)at>
PostgreSQL - Hans-Jrgen Schnig wrote:
> > Those are real problems, but I still want it. The last time I hit
> > this problem I spent two days redesigning my schema and adding
> > triggers all over the place to make things work. If I had been
> > dealing with a 30TB database instead of a 300MB database I would have
> > been royally up a creek.
> >
> > To put that another way, it's true that some people can't adjust their
> > queries, but also some people can. It's true that nonstandard stuff
> > sucks, but queries that don't work suck, too. And as for better
> > solutions, how many major release cycles do we expect people to wait
> > for them? Even one major release cycle is an eternity when you're
> > trying to get the application working before your company runs out of
> > money, and this particular problem has had a lot of cycles expended on
> > it without producing anything very tangible (proposed patch, which
> > like you I can't spare a lot of cycles to look at just now, possibly
> > excepted).
>
>
>
> cheapest and easiest solution if you run into this: add "fake" functions
> which the planner cannot estimate properly. use OR to artificially
> prop up estimates or use AND to artificially lower them. there is
> actually no need to redesign the schema to get around it but it is such
> an ugly solution that it does not even deserve to be called "ugly" ...
> however, fast and reliable way to get around it.
I agree that is super-ugly and we do need to address the cross-column
statistics better. I personally like the 2-D histogram idea:
http://archives.postgresql.org/pgsql-hackers/2010-12/msg00913.php
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
