> > > where it won't, such as when the subplan is just an unqualified select,
> > > but most of the time it should be a win, I think...)
>
> In such cases, if there are no aggregates in subquery then EXISTS
> could be used else materialization will still help.
>
> > No what Vadim is done MVCC, I would like to bug him to improve subquery
> > performance. We are tweeking the optimizer, but we have this huge
> > subquery performance problem here.
>
> No, Bruce. I'm in WAL now. I think that we need in recovery
> (remember that you'll lose indices being updated when some
> crash took place), fast backup (it's easy to copy part of log
> than dump 1Gb table), fast commits (<= 1 fsync per commit
> using group commit, instead of >= 2 fsyncs now), savepoints
> AND buffered logging, which you, Bruce, want so much,
> and so long -:).
Oh, no, I have been outmaneuvered by Vadim.
Help.
Isn't it something that takes only a few hours to implement. We can't
keep telling people to us EXISTS, especially because most SQL people
think correlated queries are slower that non-correlated ones. Can we
just on-the-fly rewrite the query to use exists?
-- Bruce Momjian | http://www.op.net/~candle maillist@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