On Thu, 2010-03-18 at 16:12 -0400, Justin Pitts wrote: > It seems to me that a separate partition / tablespace would be a much simpler approach. Do you mean a separate partition/ tablespace for _each_ index built concurrently ? > On Mar 17, 2010, at 5:18 PM, Hannu Krosing wrote: > > > 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 > > > > > > > > -- > > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-performance > -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
