| From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | "Zoltan Boszormenyi" <zb(at)cybertec(dot)at> |
| Cc: | "PostgreSQL Performance" <pgsql-performance(at)postgresql(dot)org>, "Hans-Juergen Schoenig" <hs(at)cybertec(dot)at> |
| Subject: | Re: Scalability question |
| Date: | 2008-06-11 14:13:44 |
| Message-ID: | dcc563d10806110713n7e1cff25ua527c68f09d8000c@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Jun 11, 2008 at 3:56 AM, Zoltan Boszormenyi <zb(at)cybertec(dot)at> wrote:
> Hi,
>
> I got a question about scalability in high volume insert situation
> where the table has a primary key and several non-unique indexes
> on other columns of the table. How does PostgreSQL behave
> in terms of scalability? The high volume of inserts comes from
> multiple transactions.
PostgreSQL supports initial fill rates of < 100% for indexes, so set
it to 50% filled and new entries that live near current entries will
have room to be added without having the split the btree.
PostgreSQL also allows you to easily put your indexes on other
paritions / drive arrays etc...
PostgreSQL does NOT store visibility info in the indexes, so they stay
small and updates to them are pretty fast.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Rovero | 2008-06-12 01:40:20 | 8.3.1 vs 8.2.X on HP-UX PA-RISC 11.11/11.23 |
| Previous Message | Alvaro Herrera | 2008-06-11 13:34:38 | Re: Scalability question |