Thread: ksqo?
The current KSQO code is currently #ifdef'ed out, and the 'ksqo' GUC variable does nothing. Is there a reason for keeping this code around? (or conversely, what was the original justification for disabling it?) Should I just send in a patch getting rid of it? Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Neil Conway <nconway@klamath.dyndns.org> writes:
> The current KSQO code is currently #ifdef'ed out, and the 'ksqo' GUC
> variable does nothing. Is there a reason for keeping this code around?
> (or conversely, what was the original justification for disabling it?)
I disabled it because I didn't have time to fix it properly when it got
broken by the 7.1 rewrite of UNION/INTERSECT/EXCEPT. I've been waiting
to see whether anyone notices that it's gone ;-). So far the demand for
it has been invisible, so it hasn't gotten fixed. On the other hand
I'm not quite convinced that it never will get fixed, so I haven't
applied the coup de grace.
regards, tom lane
On Wed, 22 May 2002 18:03:07 -0400 "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > Neil Conway <nconway@klamath.dyndns.org> writes: > > The current KSQO code is currently #ifdef'ed out, and the 'ksqo' GUC > > variable does nothing. Is there a reason for keeping this code around? > > (or conversely, what was the original justification for disabling it?) > > I disabled it because I didn't have time to fix it properly when it got > broken by the 7.1 rewrite of UNION/INTERSECT/EXCEPT. I've been waiting > to see whether anyone notices that it's gone ;-). So far the demand for > it has been invisible, so it hasn't gotten fixed. On the other hand > I'm not quite convinced that it never will get fixed, so I haven't > applied the coup de grace. Hmmm... Well, I'll take a look at it, but I'll probably just leave it be -- since the optimization might actually return invalid results, it doesn't seem like a very valuable thing to have, IMHO. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Neil Conway <nconway@klamath.dyndns.org> writes:
> Hmmm... Well, I'll take a look at it, but I'll probably just leave it
> be -- since the optimization might actually return invalid results, it
> doesn't seem like a very valuable thing to have, IMHO.
Yeah, I never cared for the fact that it altered the semantics of the
query, even if only subtly. But I'm hesitant to rip out something that
someone went to the trouble of writing and contributing ...
regards, tom lane
Tom Lane wrote: > Neil Conway <nconway@klamath.dyndns.org> writes: > > Hmmm... Well, I'll take a look at it, but I'll probably just leave it > > be -- since the optimization might actually return invalid results, it > > doesn't seem like a very valuable thing to have, IMHO. > > Yeah, I never cared for the fact that it altered the semantics of the > query, even if only subtly. But I'm hesitant to rip out something that > someone went to the trouble of writing and contributing ... If it does nothing, we certainly should remove it from GUC so people don't see a meaningless option. We can then keep it in CVS to see if we want it later. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > Tom Lane wrote: > > Neil Conway <nconway@klamath.dyndns.org> writes: > > > Hmmm... Well, I'll take a look at it, but I'll probably just leave it > > > be -- since the optimization might actually return invalid results, it > > > doesn't seem like a very valuable thing to have, IMHO. > > > > Yeah, I never cared for the fact that it altered the semantics of the > > query, even if only subtly. But I'm hesitant to rip out something that > > someone went to the trouble of writing and contributing ... > > If it does nothing, we certainly should remove it from GUC so people > don't see a meaningless option. We can then keep it in CVS to see if we > want it later. Here is the email from May 28 discussing the removal of GUC. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026