Re: big select is resulting in a large amount of disk writing by kjournald

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Joseph S <jks(at)selectacast(dot)net>
Subject: Re: big select is resulting in a large amount of disk writing by kjournald
Date: 2009-12-16 01:28:21
Message-ID: C74D77B5.1B5F3%scott@richrelevance.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


On 12/10/09 8:41 AM, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:

>
> There has been some talk about possibly writing tuples in a frozen
> state with the hint bits already set if they are loaded in the same
> database transaction which creates the table, but I'm not aware of
> anyone currently working on this.
>

Wow, that would be nice. That would cut in half the time it takes to
restore a several TB db (3 days to 1.5 here).

I assume this would help a lot of "CREATE TABLE AS SELECT ..." use cases
too. That is often the fastest way to do a large update on a table, but it
can still be annoyingly write intensive.

> -Kevin
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Vishal Gupta 2009-12-16 06:46:36 Parallel Function calls using multiple processes
Previous Message Robert Haas 2009-12-13 03:56:42 Re: 8.4.1 ubuntu karmic slow createdb