Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"
От | Tom Lane |
---|---|
Тема | Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" |
Дата | |
Msg-id | 27017.1336405902@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: BUG #6629: Creating a gist index fails with "too many
LWLocks taken"
Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" |
Список | pgsql-bugs |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.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
В списке pgsql-bugs по дате отправления: