Re: TB-sized databases

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: TB-sized databases
Дата
Msg-id 17456.1196963738@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: TB-sized databases  (Matthew <matthew@flymine.org>)
Ответы Re: TB-sized databases  (Matthew <matthew@flymine.org>)
Re: TB-sized databases  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Matthew <matthew@flymine.org> writes:
> ... For this query, Postgres would perform a nested loop,
> iterating over all rows in the small table, and doing a hundred index
> lookups in the big table. This completed very quickly. However, adding the
> LIMIT meant that suddenly a merge join was very attractive to the planner,
> as it estimated the first row to be returned within milliseconds, without
> needing to sort either table.

> The problem is that Postgres didn't know that the first hit in the big
> table would be about half-way through, after doing a index sequential scan
> for half a bazillion rows.

Hmm.  IIRC, there are smarts in there about whether a mergejoin can
terminate early because of disparate ranges of the two join variables.
Seems like it should be straightforward to fix it to also consider
whether the time-to-return-first-row will be bloated because of
disparate ranges.  I'll take a look --- but it's probably too late
to consider this for 8.3.

            regards, tom lane

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

Предыдущее
От: Matthew
Дата:
Сообщение: Re: TB-sized databases
Следующее
От: Matthew
Дата:
Сообщение: Re: TB-sized databases