Re: Tuning resource parameters for a logging database.

Поиск
Список
Период
Сортировка
От Vick Khera
Тема Re: Tuning resource parameters for a logging database.
Дата
Msg-id 2968dfd60905220756l2cc4a989x1fde21d8254b555f@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Tuning resource parameters for a logging database.  (Alex Thurlow <alex@blastronetworks.com>)
Ответы Re: Tuning resource parameters for a logging database.  (Alex Thurlow <alex@blastronetworks.com>)
Список pgsql-general
On Thu, May 21, 2009 at 3:37 PM, Alex Thurlow <alex@blastronetworks.com> wrote:
> I was hoping to not have to change all my code to automate the partitioning
> table creation stuff, but if that's really the best way, I'll check it out.
> Thanks for the advice.

About a 18 months ago we split a large table with 300+ million rows
into 100 partitions.  The query speed was improved by at least 2
orders of magnitude.  Postgres is exceptionally good at dealing with
tables in the 10 million row range, and that's what we gave it.  Our
primary queries on the data were able to go directly to the right
partition, but using constraint exclusion was still nearly just as
fast.

It was totally worth the 10 days or so it took to set up, test (on a
replica!) and migrate the data.  In your case you could have a natural
migration by just adding the child tables and inserting your new data
there and deleting old data from your main table.  After 30 days, your
main table will be empty and you just truncate it, freeing up all the
space.

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

Предыдущее
От: artacus@comcast.net
Дата:
Сообщение: Re: Aggregate Function to return most common value for a column
Следующее
От: Grzegorz Jaśkiewicz
Дата:
Сообщение: Re: question on serial key