> 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
theschema 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.
regards,
hans
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
