Scanning for insert

From: James William Pye <pgsql(at)jwp(dot)name>
To: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Scanning for insert
Date: 2006-03-02 21:16:10
Message-ID: 20060302211610.GA15367@lit.jwp.name
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
sfi.patch text/plain 35.5 KB

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-03-02 21:32:01 Re: [HACKERS] Spaces in psql output (Was: FW: PGBuildfarm
Previous Message Bruce Momjian 2006-03-02 20:49:20 Re: patch fixing the old RETURN NEXT bug