From: | Shaun Thomas <sthomas(at)peak6(dot)com> |
---|---|
To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, felix <crucialfelix(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Really really slow select count(*) |
Date: | 2011-02-04 19:14:14 |
Message-ID: | 4D4C5006.7030805@peak6.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 02/04/2011 01:01 PM, Scott Marlowe wrote:
> begin;
> select * into temporaryholdingtable order by somefield;
> truncate oldtable;
> insert into oldtables select * from temporaryholdingtable;
> commit;
That's usually how I do it, except for larger tables, I also throw in a
DROP INDEX for all the indexes on the table before the insert, and
CREATE INDEX statements afterwards.
Which actually brings up a question I've been wondering to myself that I
may submit to [HACKERS]: Can we add a a parallel option to the reindexdb
command? We added one to pg_restore, so we already know it works.
I have a bunch of scripts that get all the indexes in the database and
order them by size (so they're distributed evenly), round-robin them
into separate REINDEX sql files, and launches them all in parallel
depending on how many threads you want, but that's so hacky I feel dirty
every time I use it.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas(at)peak6(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email
From | Date | Subject | |
---|---|---|---|
Next Message | felix | 2011-02-04 19:26:17 | Re: Really really slow select count(*) |
Previous Message | Josh Berkus | 2011-02-04 19:05:57 | Write-heavy pg_stats_collector on mostly idle server |