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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
Дата
Msg-id 20061102191555.GL25444@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs  ("Dave Dutcher" <dave@tridecap.com>)
Ответы Re: Query plan for "heavy" SELECT with "lite" sub-SELECTs
Список 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 по дате отправления:

Предыдущее
От: Tobias Brox
Дата:
Сообщение: Re: Setting "nice" values
Следующее
От: Vivek Khera
Дата:
Сообщение: Re: VACUUMs take twice as long across all nodes