| From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Steven Flatt <steven(dot)flatt(at)gmail(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Bill Moran <wmoran(at)collaborativefusion(dot)com>, Vivek Khera <vivek(at)khera(dot)org>, Pgsql performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: When/if to Reindex |
| Date: | 2007-08-24 05:11:31 |
| Message-ID: | 46CE6883.10104@paradise.net.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Tom Lane wrote:
>
> The fly in the ointment is that after collecting the pg_index definition
> of the index, plancat.c also wants to know how big it is --- it calls
> RelationGetNumberOfBlocks. And that absolutely does look at the
> physical storage, which means it absolutely is unsafe to do in parallel
> with a REINDEX that will be dropping the old physical storage at some
> point.
>
> So maybe we are stuck and we have to say "that doesn't work anymore".
> But it feels like we might not be too far away from letting it still
> work. Thoughts, ideas?
>
A suggestion that seems a bit like a leap backwards in time - maybe just
use the pg_class.relpages entry for the index size?
I'm punting that with autovacuum being enabled by default now, the
relpages entries for all relations will be more representative than they
used to in previous releases.
Cheers
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2007-08-24 06:49:16 | Re: When/if to Reindex |
| Previous Message | Tom Lane | 2007-08-24 03:59:02 | Re: When/if to Reindex |