From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jim Nasby" <jim(dot)nasby(at)enterprisedb(dot)com> |
Cc: | "PostgreSQL-development Development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re-ordering of OR conditions |
Date: | 2007-02-09 16:46:16 |
Message-ID: | 1297.1171039576@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jim Nasby" <jim(dot)nasby(at)enterprisedb(dot)com> writes:
> IF I run the following with the a < 2900 condition first, the more
> expensive EXISTS only gets executed when needed, but if I change the
> order of the OR's, the EXISTS is always executed. It would be good if
> the optimizer could re-order the OR conditions based on estimated
> cost (granted, this wouldn't work very well if you've got functions
> in the OR, but it'd still be useful):
I looked at this for a bit. It's in principle do-able but I'm not
sure it's a good idea. The problem is that while AND'ed condition
lists are usually fairly short and hence cheap to sort, OR'ed condition
lists are not infrequently very long --- nobody blinks an eye at
hundreds of items in an IN-list for instance. I'm afraid we'd waste
a lot more cycles sorting than we could hope to regain.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-02-09 16:50:05 | Re: Variable length varlena headers redux |
Previous Message | Gregory Stark | 2007-02-09 16:39:03 | Re: Hierarchical Queries--Status |