| From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | 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 20:49:01 |
| Message-ID: | 4BA1403D.9030402@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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 work often with time-oriented apps that
have heavy "give me every record between <a> and <b>" components to
them, and good sequential index performance can be an important
requirement for that kind of application.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2010-03-17 21:18:47 | Re: Building multiple indexes concurrently |
| Previous Message | Alvaro Herrera | 2010-03-17 20:24:01 | Re: Building multiple indexes concurrently |