Re: Why does postgres seach in ALL lines (not optimal!)

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: Why does postgres seach in ALL lines (not optimal!)
Дата
Msg-id 20021028085510.O79386-100000@megazone23.bigpanda.com
обсуждение исходный текст
Ответ на Why does postgres seach in ALL lines (not optimal!)  (markus.cl@gmx.de (Markus Dehmann))
Список pgsql-general
On 24 Oct 2002, Markus Dehmann wrote:

> Hi,
>
> I have two tables with entries that have the same IDs. My select shall
> get all entries from both tables that have an ID > 19000, all in all I
> have 19577 entries.
>
> select * from m, t where m.id > 19000 and t.messageid = m.id;
>
> Postgres should immediately get the 577 lines from m, and get the
> corresponding 577 lines from table t, using the primary keys. But, it
> scans ALL the lines in table t which seems highly inefficient:
>
> db=# EXPLAIN select * from m, t
> db-# where m.id > 19000 and t.messageid = m.id;
>
> Merge Join  (cost=0.00..628.96 rows=550 width=172)
>   ->  Index Scan using pk_m on m  (cost=0.00..17.43  rows=  550
> width=101)
>   ->  Index Scan using pk_t on t  (cost=0.00..554.34 rows=19576 (!!!)
> width=71)
>
> Why is this and how can I make postgres search fewer rows in the table
> t?

Well, it seems to want to do a merge join which doesn't seem like a bad
idea.  It doesn't imply t.messageid>19000 from the two clauses above.  You
could probably add it which might make a happier seeming plan, although
I'm not sure it'd help much in actual execution.  Without
t.messageid>19000 it's basically using the index scan on t to get the rows
in sorted order to do the merge.



В списке pgsql-general по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: VACUUM FULL not working with persistent connections
Следующее
От: Darko Prenosil
Дата:
Сообщение: Re: Binary Large Objects