From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dawid Kuroczko <qnex42(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Views, joins and LIMIT |
Date: | 2004-10-11 14:14:18 |
Message-ID: | 4865.1097504058@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Dawid Kuroczko <qnex42(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-11 14:22:03 | Re: COPY slows down? |
Previous Message | Janning Vygen | 2004-10-11 12:25:02 | Re: why my query is not using index?? |