Re: Table Partitions / Partial Indexes
| От | Mike C |
|---|---|
| Тема | Re: Table Partitions / Partial Indexes |
| Дата | |
| Msg-id | bd0eabd0512131554v451a99f2u4ac64e403e9b6b49@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Table Partitions / Partial Indexes (Simon Riggs <simon@2ndquadrant.com>) |
| Список | pgsql-performance |
On 12/14/05, Simon Riggs <simon@2ndquadrant.com> wrote:
That's an interesting idea, thanks.
I was trying to get both the indexes to be smaller without loosing selectivity, and make any table scans/index scans faster from having to read less data.
Ideally that's what I would do, but to make the most of that I would have to have a dedicated RAID setup for each partition right? (Which is a bit pricey for the budget).
Cheers,
Mike
Maybe not for queries, but if you use a date range then you never need
to run a DELETE and never need to VACUUM.
You could split the data into two-day chunks.
That's an interesting idea, thanks.
> Am I using a horrid method for partitioning the data? (% 10)
No, but what benefit do you think it provides. I'm not sure I see...
I was trying to get both the indexes to be smaller without loosing selectivity, and make any table scans/index scans faster from having to read less data.
> Should there be that big of an improvement for multiple tables given
> that all the data is still stored on the same filesystem?
You could store partitions in separate tablespaces/filesystems.
Ideally that's what I would do, but to make the most of that I would have to have a dedicated RAID setup for each partition right? (Which is a bit pricey for the budget).
Cheers,
Mike
В списке pgsql-performance по дате отправления: