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