Re: Info about concurrent sequential scans

Поиск
Список
Период
Сортировка
От Andreas Kretschmer
Тема Re: Info about concurrent sequential scans
Дата
Msg-id 20100222195900.GA14260@tux
обсуждение исходный текст
Ответ на Info about concurrent sequential scans  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Ответы Re: Info about concurrent sequential scans  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Список pgsql-general
Daniele Varrazzo <daniele.varrazzo@gmail.com> wrote:

> Hello,
>
> at Prato PgDay in 2007 I remember hearing in a speech about a (then
> yet to come) "seqscan piggyback" feature, allowing concurrent
> sequential scans to use the same disk reads. I've now googled for info
> about this feature, but I found nothing conclusive (e.g. [1], [2] -
> which I don't know where is linked).
>
> So I'd like to know:
>
> is this feature currently implemented (I'm specifically interested in PG 8.3)?

I think, you means this:

 Concurrent large sequential scans can now share disk reads (Jeff Davis)

This is accomplished by starting the new sequential scan in the middle
of the table (where another sequential scan is already in-progress) and
wrapping around to the beginning to finish. This can affect the order of
returned rows in a query that does not specify ORDER BY. The
synchronize_seqscans configuration parameter can be used to disable this
if necessary

Source:
http://www.postgresql.org/docs/current/interactive/release-8-3.html


> Is there any prerequisite needed to benefit from it (config setting,
> query characteristic, etc.)?

No.



Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect.                              (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly."   (unknown)
Kaufbach, Saxony, Germany, Europe.              N 51.05082°, E 13.56889°

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

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: Sorting performance vs. MySQL
Следующее
От: Yang Zhang
Дата:
Сообщение: Re: Sorting performance vs. MySQL