Tom Lane wrote:
> Actually, in the type of case Mark is showing, the estimates might
> be *more* accurate since the condition gets decomposed into
> separate per-table conditions. I'm still dubious about how often
> it's a win though.
>
> There's another problem, which is that transforming to
Robert Haas writes:
> On Tue, Jan 26, 2010 at 11:41 AM, Tom Lane wrote:
>> I'd suggest going with the UNION. We are unlikely to make the planner
>> look for such cases, because usually such a transformation would be a
>> net loss. It seems like rather a corner case that it's a win even on
>> yo
On Tue, Jan 26, 2010 at 11:41 AM, Tom Lane wrote:
> Mark Hills writes:
>> One of our most-used queries performs poorly (taking over 2 seconds) and a
>> tiny amount of refactoring shows it can be fast (less than 1ms) by
>> transforming the OR case (which spans two tables) into a UNION.
>
> I'd sug
Mark Hills writes:
> One of our most-used queries performs poorly (taking over 2 seconds) and a
> tiny amount of refactoring shows it can be fast (less than 1ms) by
> transforming the OR case (which spans two tables) into a UNION.
I'd suggest going with the UNION. We are unlikely to make the p
just create index on both columns:
CREATE INDEX foo_i ON foo(bar1, bar2);
HTH
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
One of our most-used queries performs poorly (taking over 2 seconds) and a
tiny amount of refactoring shows it can be fast (less than 1ms) by
transforming the OR case (which spans two tables) into a UNION.
I have created a simple test case (below) which shows the difference we
are seeing in que
