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
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 |
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 |