Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: [GENERAL] Concurrency problem building indexes
- From: "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at>
- To: "Wes" <wespvp(at)syntegra(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
- Cc: "Jim C. Nasby" <jnasby(at)pervasive(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
- Subject: Re: [GENERAL] Concurrency problem building indexes
- Date: Tue, 25 Apr 2006 16:55:00 +0200
- Message-id: <E1539E0ED7043848906A8FF995BDA579FC326B(at)m0143(dot)s-mxs(dot)net>
> > Wes, you could most likely solve your immediate problem if you did an > > analyze before creating the indexes. > > I can try that. Is that going to be a reasonable thing to do when there's > 100 million rows per table? I obviously want to minimize the number of > sequential passes through the database. No, I think it would only help if it gets the exact tuple count. For large tables it only gets an exact count with a full scan (use vacuum instead of analyze). Then again, when the table is large, the different "create index"es should finish at sufficiently different times, so an analyze might be sufficient to fix the problem for small tables. (analyze is fast for large tables since it only does a sample) Andreas
- Prev by Date: Re: [PATCHES] Implementing RESET CONNECTION ...
- Next by Date: Re: [GENERAL] Concurrency problem building indexes
- Previous by thread: Re: Catalog Access
- Next by thread: Summary of coverity bugs
- Indexes: