Re: How to force subquery scan?

From: "Tambet Matiisen" <t(dot)matiisen(at)aprote(dot)ee>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <ch(at)rodos(dot)fzk(dot)de>, <pgsql-sql(at)postgresql(dot)org>
Subject: Re: How to force subquery scan?
Date: 2005-03-17 08:39:43
Message-ID: A66A11DBF5525341AEF6B8DE39CDE77008805A@black.aprote.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Wednesday, March 16, 2005 5:42 PM
> To: Tambet Matiisen
> Cc: ch(at)rodos(dot)fzk(dot)de; pgsql-sql(at)postgresql(dot)org
> Subject: Re: [SQL] How to force subquery scan?
>
>
> "Tambet Matiisen" <t(dot)matiisen(at)aprote(dot)ee> writes:
> > It seems that subquery scan is only used, when the query can not be
> > translated into single flat query. Which is mostly good, I assume.
>
> The planner thinks so anyway ;-)
>
> If you're desperate you can put in an optimization fence, for
> instance LIMIT or OFFSET.
>
> SELECT * FROM (SELECT ... OFFSET 0) ss;
>
> In principle the planner could figure out that this offset is
> a no-op, throw it away, and then flatten the query. But it
> doesn't at the moment, and I doubt we'll teach it to do so in
> the future.
>
> regards, tom lane
>

Thanks, that did the trick. It was a bit more strict than expected,
because WHERE of the outer query is not optimized into subquery. But
considering the semantics of OFFSET that seems reasonable and I can work
around it for now.

Tambet

Browse pgsql-sql by date

  From Date Subject
Next Message Chandan_Kumaraiah 2005-03-17 10:57:34 query
Previous Message Phil Daintree 2005-03-17 08:20:20 Query performance problem