| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kelly Burkhart <kelly(at)tradebotsystems(dot)com> |
| Cc: | mark(at)mark(dot)mielke(dot)cc, Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: 8.x index insert performance |
| Date: | 2005-10-31 21:18:47 |
| Message-ID: | 19065.1130793527@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Kelly Burkhart <kelly(at)tradebotsystems(dot)com> writes:
> Ha! So I'm creating an index 98% full of nulls! Looks like this is
> easily fixed with partial indexes.
Still, though, it's not immediately clear why you'd be seeing a severe
dropoff in insert performance after 50M rows. Even though there are
lots of nulls, I don't see why they'd behave any worse for insert speed
than real data. One would like to think that the insert speed would
follow a nice O(log N) rule.
Are you doing the inserts all in one transaction, or several? If
several, could you get a gprof profile of inserting the same number of
rows (say a million or so) both before and after the unexpected dropoff
occurs?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PostgreSQL | 2005-10-31 23:16:46 | 8.1beta3 performance |
| Previous Message | Merlin Moncure | 2005-10-31 21:10:57 | Re: 8.x index insert performance |