Re: Views, joins and LIMIT - Mailing list pgsql-performance

From Tom Lane
Subject Re: Views, joins and LIMIT
Date
Msg-id 4865.1097504058@sss.pgh.pa.us
Whole thread Raw
In response to Views, joins and LIMIT  (Dawid Kuroczko <qnex42@gmail.com>)
List pgsql-performance
Dawid Kuroczko <qnex42@gmail.com> writes:
> This I guess would be quite benefitial for VIEWs. :)

Have you tried it?

regression-# SELECT entry_id,message FROM entries NATURAL JOIN messages ORDER BY entry_id DESC LIMIT 10;
                                             QUERY PLAN

-----------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..48.88 rows=10 width=36)
   ->  Nested Loop  (cost=0.00..4887.52 rows=1000 width=36)
         ->  Index Scan Backward using entries_pkey on entries  (cost=0.00..52.00 rows=1000 width=8)
         ->  Index Scan using messages_pkey on messages  (cost=0.00..4.82 rows=1 width=36)
               Index Cond: ("outer".message_id = messages.message_id)
(5 rows)

> Other thing that would be, I guess, benefitial for views would be
> special handling of lines like this:

> SELECT entry_id,message_id FROM entries NATURAL JOIN messages;

> Here there is no reason to perform JOIN at all -- the data will not be used.
> As above, since entries.message_id IS NOT NULL REFERENCES messages
> and messages is UNIQUE (PRIMARY KEY) we are sure there will be one-to-one(*)
> mapping between two tables.  And since these keys are not used, no need to
> waste time and perform JOIN.

The bang-for-the-buck ratio on that seems much too low.

            regards, tom lane

pgsql-performance by date:

Previous
From: Janning Vygen
Date:
Subject: Re: why my query is not using index??
Next
From: Tom Lane
Date:
Subject: Re: COPY slows down?