| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | tom(at)tomforb(dot)es, pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" |
| Date: | 2012-05-07 15:51:42 |
| Message-ID: | 27017.1336405902@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> We could rearrange the page splitting algorithm to release locks
> earlier, before traversing to the next parent level.
That seems like a good idea just on concurrency grounds; I'm worried
about both the performance implications and the risk of deadlock.
> I wrote a quick patch to do that, and with the patch the index build
> finished - but it took hours. And the index was 10GB in size, where the
> heap is just 12 MB, and searches using the index take ages.
Hm, is the example exploiting some pessimal behavior in the picksplit
logic for the particular opclass? Maybe that's something to fix, too.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | tom Tom | 2012-05-07 16:31:40 | Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" |
| Previous Message | Heikki Linnakangas | 2012-05-07 15:37:27 | Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" |