Re: Vacuum-full very slow

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Listmail" <lists(at)peufeu(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Steve Crawford" <scrawford(at)pinpointresearch(dot)com>, <pgsql-general(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vacuum-full very slow
Date: 2007-04-26 07:21:15
Message-ID: 1177572075.4934.42.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, 2007-04-26 at 00:13 +0200, Listmail wrote:
> By the way, about indexes :
>
> When you have a small table (say, for a website, maybe a few
> tens of
> megabytes max...) reindexing it takes just a few seconds, maybe
> 10-20
> seconds.
> It could be interesting, performance-wise, to tell postgres
> not to bother
> about crash-survivability of indexes on this table. Like temporary
> tables.
> Write nothing to WAL. If it crashes, on recovery, postgres would
> reindex
> the table.
> btree indexing is so fast on postgres that I'd definitely use
> this
> feature.
> I'd rather trade a minute of recovery versus less disk IO for
> index
> update.
>
> You could even do that for whole tables (like, web sessions
> table) which
> hold "perishable" data...

That optimisation on mine/Heikki's todo for the next release.

In some cases it can speed up recovery, as well as mainline performance.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message pobox@verysmall.org 2007-04-26 07:59:04 Re: pg_connect sometimes works sometimes not
Previous Message A. Kretschmer 2007-04-26 05:17:46 Re: Business days

Browse pgsql-hackers by date

  From Date Subject
Next Message Alban Hertroys 2007-04-26 08:07:46 Re: Schema as versioning strategy
Previous Message Stefan Kaltenbrunner 2007-04-26 04:44:51 Re: strange buildfarm failures