Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs - Mailing list pgsql-performance

From Alvaro Herrera
Subject Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
Date
Msg-id 20061102191555.GL25444@alvh.no-ip.org
Whole thread Raw
In response to Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs  ("Dave Dutcher" <dave@tridecap.com>)
Responses Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
List pgsql-performance
Dave Dutcher wrote:
> > -----Original Message-----
> > From: pgsql-performance-owner@postgresql.org
> > Nikolay Samokhvalov
> >
> > What should I do to make Postgres work properly in such cases (I have
> > a lot of similar queries; surely, they are executed w/o seqscans, but
> > overall picture is the same - I see that starting from sub-selects
> > dramatically decrease performance)?
>
> How about this:
>
> explain analyze
> select (select typname from pg_type where pg_type.oid=mainq.prorettype limit
> 1)
> from (select * from pg_proc offset 1500 limit 1) mainq;

What's the use of such a query?  One would think that in the real world,
you'd at least have an ORDER BY somewhere in the subqueries.

Performance analysis of strange queries is useful, but the input queries
have to be meaningful as well.  Otherwise you end up optimizing bizarre
and useless cases.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

pgsql-performance by date:

Previous
From: Tobias Brox
Date:
Subject: Re: Setting "nice" values
Next
From: Vivek Khera
Date:
Subject: Re: VACUUMs take twice as long across all nodes