On Mon, Jul 28, 2014 at 11:37:07AM -0400, Robert Haas wrote:
> > Yes, but what if you don't see a conflict because it isn't visible to
> > your snapshot, and then you insert, and only then (step 5), presumably
> > with a dirty snapshot, you find a conflict? How does the loop
> > terminate if that b
On Wed, Jul 30, 2014 at 10:36 AM, Robert Haas wrote:
> You've convinced me that only indexable predicates can be sensibly
> used here. I'm not sure that's the same as saying that upserts are
> driven by inserts, though. I'd tend to interpret that to mean
> insert-the-heap-tuple-first, but I thin
On Tue, Jul 29, 2014 at 1:28 PM, Peter Geoghegan wrote:
> On Tue, Jul 29, 2014 at 9:56 AM, Robert Haas wrote:
>> 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 con
On Tue, Jul 29, 2014 at 9:56 AM, Robert Haas wrote:
> 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
On Mon, Jul 28, 2014 at 1:43 PM, Peter Geoghegan wrote:
> On Mon, Jul 28, 2014 at 8:37 AM, Robert Haas 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
>
On Mon, Jul 28, 2014 at 10:43 AM, Peter Geoghegan wrote:
> On a mostly unrelated note, I'll remind you of the reason that I felt
> it was best to lock indexes. It wasn't so much about avoiding bloat as
> it was about avoiding deadlocks. When I highlighted the issue,
> Heikki's prototype, which did
On Mon, Jul 28, 2014 at 10:43 AM, Peter Geoghegan wrote:
> Plus, I ask you to
> consider that.
Excuse me. I meant "Plus, you avoid bloat. I ask you to consider that".
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
On Mon, Jul 28, 2014 at 8:37 AM, Robert Haas 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 o
On Wed, Jul 23, 2014 at 7:35 PM, Peter Geoghegan wrote:
>> It's certain arguable whether you should INSERT and then turn failures
>> into an update or try to UPDATE and then turn failures into an INSERT;
>> we might even want to have both options available, though that smells
>> a little like airi
On Wed, Jul 23, 2014 at 7:32 PM, Alvaro Herrera
wrote:
>> Because nobody wants an operation to either insert 1 tuple or update
>> n>=1 tuples. The intention is that the predicate should probably be
>> something like WHERE unique_key = 'some_value', but you can use
>> something else. So it's kind
On Wed, Jul 23, 2014 at 9:58 AM, Robert Haas wrote:
> I'd suggest something like:
>
> UPSERT table SET col = value [, ...] WHERE predicate;
I think I see another problem with this. The UPDATE must provide a
WHERE clause Var on a unique indexed column (let's say it's
constrained to provide a "(Var
On Wed, Jul 23, 2014 at 3:27 PM, Robert Haas wrote:
> To the last question, yes. To the first point, I'm not bent on this
> particular syntax, but I am +1 for the idea that the command is
> something specifically upsert-like rather than something more generic
> like an ON CONFLICT SELECT that let
Robert Haas wrote:
> On Wed, Jul 23, 2014 at 4:05 PM, Peter Geoghegan wrote:
> > On Wed, Jul 23, 2014 at 9:58 AM, Robert Haas wrote:
> >> 2. If you find more than one tuple that is visible to your scan, error.
> >
> > This point seems to concern making the UPSERT UPDATE only affect zero
> > or o
On Wed, Jul 23, 2014 at 3:01 PM, Kevin Grittner wrote:
> Could you clarify that? Does this mean that you feel that we
> should write to the heap before reading the index to see if the row
> will be a duplicate? If so, I think that is a bad idea, since this
> will sometimes be used to apply a new
Peter Geoghegan-3 wrote
>> with semantics like this:
>>
>> 1. Search the table, using any type of scan you like, for a row
>> matching the given predicate.
>
> Perhaps I've misunderstood, but this is fundamentally different to
> what I'd always thought would need to happen. I always understood tha
On Wed, Jul 23, 2014 at 4:05 PM, Peter Geoghegan wrote:
> On Wed, Jul 23, 2014 at 9:58 AM, Robert Haas wrote:
>> This all seems completely to one side of Andres's point. I think what
>> he's saying is: don't implement an SQL syntax of the form INSERT ON
>> CONFLICT and let people use that to imp
Peter Geoghegan wrote:
> I still strongly feel it ought to be driven by an insert
Could you clarify that? Does this mean that you feel that we
should write to the heap before reading the index to see if the row
will be a duplicate? If so, I think that is a bad idea, since this
will sometimes b
On Wed, Jul 23, 2014 at 5:58 PM, Robert Haas wrote:
> I'd suggest something like:
>
> UPSERT table SET col = value [, ...] WHERE predicate;
I don't think this is actually good enough. Typical use cases are
things like "increment this counter or insert a new one starting at
0".
--
greg
--
Sen
On Wed, Jul 23, 2014 at 9:58 AM, Robert Haas wrote:
> This all seems completely to one side of Andres's point. I think what
> he's saying is: don't implement an SQL syntax of the form INSERT ON
> CONFLICT and let people use that to implement upsert. Instead,
> directly implement an SQL command c
On Sat, Jul 19, 2014 at 10:04 PM, Peter Geoghegan wrote:
> On Fri, Jul 18, 2014 at 11:23 AM, Andres Freund
> wrote:
>> Meh. A understandable syntax wouldn't require the pullups with a special
>> scan node and such.
>
> Well, in general ExecModifyTable()/ExecUpdate() trusts the tid passed
> to ma
On Fri, Jul 18, 2014 at 11:23 AM, Andres Freund wrote:
> Meh. A understandable syntax wouldn't require the pullups with a special
> scan node and such.
Well, in general ExecModifyTable()/ExecUpdate() trusts the tid passed
to match the qual in the query. Unless you're willing to give up on
the ide
On Fri, Jul 18, 2014 at 11:32 AM, Peter Geoghegan wrote:
> Well, maybe. If the genericity of this syntax isn't what people want,
> I may go with something else.
By the way, I didn't mention that there is now also the optional
ability to specify a "merge on" unique index directly in DML. It would
On Fri, Jul 18, 2014 at 11:23 AM, Andres Freund wrote:
> Meh. A understandable syntax wouldn't require the pullups with a special
> scan node and such. I think you're attempting a sort of genericity
> that's making your (important!) goal much harder to reach.
Well, maybe. If the genericity of thi
On 2014-07-18 11:14:34 -0700, Peter Geoghegan wrote:
> On Fri, Jul 18, 2014 at 11:06 AM, Andres Freund
> wrote:
> > I don't see why you'd need such a node at all if we had a fully builtin
> > UPSERT. The whole stuff with ON CONFLICT SELECT FOR UPDATE and then
> > UPDATE ... FROM c CONFLICTS is to
On Fri, Jul 18, 2014 at 11:06 AM, Andres Freund wrote:
> I don't see why you'd need such a node at all if we had a fully builtin
> UPSERT. The whole stuff with ON CONFLICT SELECT FOR UPDATE and then
> UPDATE ... FROM c CONFLICTS is too complicated and exposes stuff that
> barely anybody will under
On 2014-07-18 10:53:36 -0700, Peter Geoghegan wrote:
> On Fri, Jul 18, 2014 at 10:46 AM, Andres Freund
> wrote:
> > I think the things that use "wierd" visibility semantics are pretty much
> > all doing that internally (things being EvalPlanQual stuff for
> > INSERT/UPDATE/DELETE and the referent
On Fri, Jul 18, 2014 at 10:46 AM, Andres Freund wrote:
> I think the things that use "wierd" visibility semantics are pretty much
> all doing that internally (things being EvalPlanQual stuff for
> INSERT/UPDATE/DELETE and the referential integrity triggers). I don't
> see sufficient reason why we
Hi,
On 2014-07-17 18:18:41 -0700, Peter Geoghegan wrote:
> I'm working on UPSERT again. I think that in order to make useful
> progress, I'll have to find a better way of overcoming the visibility
> issues (i.e. the problem of what to do about a
> still-in-progress-to-our-snapshot row being locked
On Thu, Jul 17, 2014 at 6:18 PM, Peter Geoghegan wrote:
> This appears to be a Simple Matter of Programming (at least
> for someone that happens to already have a good understanding of the
> optimizer), and is anticipated by this comment within tidpath.c:
>
> * There is currently no special suppo
I'm working on UPSERT again. I think that in order to make useful
progress, I'll have to find a better way of overcoming the visibility
issues (i.e. the problem of what to do about a
still-in-progress-to-our-snapshot row being locked at READ COMMITTED
isolation level [1][2]).
I've made some tentat
30 matches
Mail list logo
