| From: | Hannu Krosing <hannu(at)2ndquadrant(dot)com> |
|---|---|
| To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-performance(at)postgresql(dot)org, Rob Wultsch <wultsch(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Building multiple indexes concurrently |
| Date: | 2010-03-17 21:18:47 |
| Message-ID: | 1268860727.19220.1089.camel@hvost |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, 2010-03-17 at 16:49 -0400, Greg Smith wrote:
> Alvaro Herrera wrote:
> > Andres Freund escribió:
> >
> >
> >> I find it way much easier to believe such issues exist on a tables in
> >> constrast to indexes. The likelihood to get sequential accesses on an index is
> >> small enough on a big table to make it unlikely to matter much.
> >>
> >
> > Vacuum walks indexes sequentially, for one.
> >
>
> That and index-based range scans were the main two use-cases I was
> concerned would be degraded by interleaving index builds, compared with
> doing them in succession.
I guess that tweaking file systems to allocate in bigger chunks help
here ? I know that xfs can be tuned in that regard, but how about other
common file systems like ext3 ?
-
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christian Brink | 2010-03-17 21:25:35 | Forcing index scan on query produces 16x faster |
| Previous Message | Greg Smith | 2010-03-17 20:49:01 | Re: Building multiple indexes concurrently |