On Mon, Jul 28, 2014 at 1:43 PM, Peter Geoghegan <p...@heroku.com> wrote:
> On Mon, Jul 28, 2014 at 8:37 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> AFAIUI, this is because your implementation uses lwlocks in a way that
>> Andres and I both find unacceptable.
>
> That's not the case. My implementation uses page-level heavyweight
> locks. The nbtree AM used to use them for other stuff. Plenty of other
> systems use index level locks managed by a heavyweight lock manager.
Oh, OK. I think I missed that development somewhere.
>> Good point. Maybe the syntax should be something like:
>>
>> UPSERT table (keycol [, keycol] ...) { VALUES (val [, val] ...) [,
>> ...] | select_query }
>>
>> That would address both the concern about being able to pipe multiple
>> tuples through it and the point you just raised. We look for a row
>> that matches each given tuple on the key columns; if one is found, we
>> update it; if none is found, we insert.
>
> That basically is my design, except that (tangentially) yours risks
> bloat in exchange for not having to use a real locking mechanism, and
> has a different syntax.
I think it would be advisable to separate the syntax from the
implementation. Presumably you can make your implementation use some
reasonable syntax we can all agree on, and conversely my proposed
syntax could be made to have a different set of semantics. There's
some connection between the syntax and semantics, of course, but it's
not 100%. I mention this because I was mostly concerned with getting
to a reasonable syntax proposal, not so much the implementation
details. It may well be that your implementation details are perfect
at this point; I don't know because I haven't looked, and I'm not an
expert on that area of the code anyway. But I have looked at your
syntax, which I wasn't altogether keen on.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
