Skip site navigation (1) Skip section navigation (2)

Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Dave Dutcher <dave(at)tridecap(dot)com>
Cc: nikolay(at)samokhvalov(dot)com, pgsql-performance(at)postgresql(dot)org
Subject: Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
Date: 2006-11-02 19:15:55
Message-ID: 20061102191555.GL25444@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-performance
Dave Dutcher wrote:
> > -----Original Message-----
> > From: pgsql-performance-owner(at)postgresql(dot)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

In response to

Responses

pgsql-performance by date

Next:From: Vivek KheraDate: 2006-11-02 21:41:35
Subject: Re: VACUUMs take twice as long across all nodes
Previous:From: Tobias BroxDate: 2006-11-02 16:00:57
Subject: Re: Setting "nice" values

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group