This is a discussion on Scanning for insert within the Pgsql Patches forums, part of the PostgreSQL category; --> Ok. Here's a `gmake check` passing version that actually makes use of the new AM entries in ExecInsert. Currently, ...
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match |
| ||||
| James William Pye <pgsql@jwp.name> writes: > 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. So in other words, a two-step process is wrong. > Besides that I think it's ready for review. Don't think I really need to read any further ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster |
| Thread Tools | |
| Display Modes | |
|
|