Scanning for insert
От | James William Pye |
---|---|
Тема | Scanning for insert |
Дата | |
Msg-id | 20060302211610.GA15367@lit.jwp.name обсуждение исходный текст |
Ответы |
Re: Scanning for insert
|
Список | pgsql-patches |
Ok. Here's a `gmake check` passing version that actually makes use of the new AM entries in ExecInsert. Currently, AFAICS, this *only* provides an improvement for systems that frequently insert duplicate rows. Perhaps not a common case, but an improvement nonetheless, IMO. I leaned in this direction(insert scans) for the handling of unique violations as it seemed like a better idea to check ahead of time than to recover after the fact. Being able to do checks ahead of time simply allows one to eliminate the need for unwinding code. (Simply, think about not needing to heap_delete in error log cases. [Well, potentially ;]) The problem with the AM no longer having the ability to make guarantees about lock/state duration seems more or less unavoidable with this two-step process. I'm not sure that I can actually resolve any concerns involved with the transference of responsibility to the user of the AM. Currently, in ExecInsert(), I not-so-safely assume that a index implements scanforinsert if it's unique. This appears to be safe as far as all the stock AMs are concerned. However, it will likely throw an exception for indexes that are said to be unique whose AM doesn't implement scanforinsert (thinking of external AMs?). I imagine this is something that I should fix, yes? Besides that I think it's ready for review. -- Regards, James William Pye
Вложения
В списке pgsql-patches по дате отправления: