Re: [HACKERS] Idea for speeding up uncorrelated subqueries

> > > 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