Skip site navigation (1) Skip section navigation (2)

Re: Best possible way to insert and get returned ids

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Jason Dictos <jdictos(at)barracuda(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Best possible way to insert and get returned ids
Date: 2009-11-23 21:55:07
Message-ID: dcc563d10911231355r6839f7dck22aaa996d0c9bac4@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Mon, Nov 23, 2009 at 1:53 PM, Jason Dictos <jdictos(at)barracuda(dot)com> wrote:
> Question:
>
> Is an INSERT command with a SELECT statement in the RETURNING * parameter
> faster than say an INSERT and then a SELECT? Does the RETURNING * parameter
> simply amount to a normal SELECT command on the added rows? We need to
> basically insert a lot of rows as fast as possible, and get the ids that
> were added.  The number of rows we are inserting is dynamic and is not of
> fixed length.

Well, if you do an insert, then a select, how can you tell, with that
select, which rows you just inserted?  how can you be sure they're not
somebody elses?

Insert returning is fantastic for this type of thing.  The beauty of
it is that it returns a SET if you insert multiple rows.  And, if
you've got two insert threads running, and one inserts to a sequence a
set of rows with pk values of 10,11,13,15,18,20 while another thread
inserts to the same table and creates a set of rows with pk values of
12,14,16,17,19 then those are the two sets you'll get back with
returning.

In response to

pgsql-performance by date

Next:From: Faheem MithaDate: 2009-11-23 22:47:15
Subject: query optimization
Previous:From: Tom LaneDate: 2009-11-23 21:26:48
Subject: Re: Strange performance degradation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group