Re: Question about shared_buffer cache behavior
От | Rakesh Kumar |
---|---|
Тема | Re: Question about shared_buffer cache behavior |
Дата | |
Msg-id | CAJBB=EVQyyo4E7MU3cJJo4H8A4ToSUBr-ize8UDaGEevDBj5JQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Question about shared_buffer cache behavior (Paul Jones <pbj@cmicdo.com>) |
Список | pgsql-general |
PG loads data at the block level to shared_buffers. Most likely it is because the second sql selects different set of rows (from different blocks) than the first sql. On Fri, Mar 18, 2016 at 4:24 PM, Paul Jones <pbj@cmicdo.com> wrote: > In Postgres 9.5.1 with a shared_buffer cache of 7Gb, a SELECT from > a single table that uses an index appears to read the table into the > shared_buffer cache. Then, as many times as the exact same SELECT is > repeated in the same session, it runs blazingly fast and doesn't even > touch the disk. All good. > > Now, in the *same* session, if a different SELECT from the *same* table, > using the *same* index is run, it appears to read the entire table from > disk again. > > Why is this? Is there something about the query that qualifies the > contents of the share_buffer cache? Would this act differently for > different kinds of indexes? > > PJ > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: