PostgreSQL - Hans-J?rgen Sch?nig 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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers