Re: Paritioning vs. caching

Поиск
Список
Период
Сортировка
От Anj Adu
Тема Re: Paritioning vs. caching
Дата
Msg-id f2fd819a1003081127j14632bc2h8b102cef93b08b89@mail.gmail.com
обсуждение исходный текст
Ответ на Paritioning vs. caching  (Konrad Garus <konrad.garus@gmail.com>)
Список pgsql-performance
If the partitioned column in your where clause does not use hardcoded
values ...e.g datecolumn between 'year1' and 'year2' ..the query
planner will check all partitions ..this is a known issue with the
optimizer

On Mon, Mar 8, 2010 at 10:28 AM, Konrad Garus <konrad.garus@gmail.com> wrote:
> Hello,
>
> I am evaluating a materialized view implemented as partitioned table.
> At the moment the table is partitioned yearly and contains 5
> numeric/timestamp columns. One of the columns is ID (but it's not what
> the table is partitioned on).
>
> Partition for one year occupies about 1200 MB. Each of the columns is
> indexed, with each index weighing about 160 MB. I am trying to avoid
> RAM/disk thrashing. Now I have the following questions:
>
> 1. When I query the table by ID, it performs index scan on each
> partition. The result is only found in one partition, but I understand
> why it needs to look in all of them. How much disk reading does it
> involve? Is only the "head" of indexes for partitions that do not
> include the row scanned, or are always whole indexes read? I would
> like to know the general rule for index scans.
>
> 2. Is it possible to tell which PG objects are read from disk (because
> they were not found in RAM)?
>
> Thank you.
>
> --
> Konrad Garus
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

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

Предыдущее
От: Konrad Garus
Дата:
Сообщение: Paritioning vs. caching
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Paritioning vs. caching