Skip site navigation (1) Skip section navigation (2)

Re: Building multiple indexes concurrently

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 (view raw or flat)
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



In response to

Responses

pgsql-performance by date

Next:From: Christian BrinkDate: 2010-03-17 21:25:35
Subject: Forcing index scan on query produces 16x faster
Previous:From: Greg SmithDate: 2010-03-17 20:49:01
Subject: Re: Building multiple indexes concurrently

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group