From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "gary(dot)wolfe" <gary(dot)wolfe(at)biosourcetechnologies(dot)com> |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: set command |
Date: | 2000-01-21 19:03:15 |
Message-ID: | 16452.948481395@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"gary.wolfe" <gary(dot)wolfe(at)biosourcetechnologies(dot)com> writes:
> Are there any disadvantages to having KSQO='on' instead
> of the default value of "OFF"
Other than it being a kluge, you mean ;-) ?
Basically it rewrites queries with long strings of ORs into SELECT UNION
SELECT queries, which the optimizer can cope with a little better.
Unfortunately the semantics aren't really quite the same, since UNION
implies a DISTINCT pass over the output --- the UNION form will never
emit two identical rows, whereas the original query would have if there
were identical input rows.
I'm hoping to get rid of KSQO soon by upgrading the optimizer to
the point where it doesn't choke on big ORs. In the meantime, though,
you really don't have much choice if your application requires queries
with lots of ORs.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-01-21 19:06:31 | Re: vacuum timings |
Previous Message | The Hermit Hacker | 2000-01-21 18:45:34 | Re: [HACKERS] Re: vacuum timings |