Thread: Delay INSERT
Hi Does PostgreSQL have something like "INSERT DELAYD" - like it is used in MySQL? or any other way to delay inserting? Thanx
On Wed, Mar 23, 2005 at 07:31:22PM +0300, ON.KG wrote: > Does PostgreSQL have something like "INSERT DELAYD" - like it is used in > MySQL? > > or any other way to delay inserting? What problem are you trying to solve? Are you aware that PostgreSQL uses Multiversion Concurrency Control (MVCC) so readers and writers don't block each other? http://www.postgresql.org/docs/8.0/static/mvcc.html -- Michael Fuhr http://www.fuhr.org/~mfuhr/
ON.KG wrote: > Hi > > Does PostgreSQL have something like "INSERT DELAYD" - like it is used in > MySQL? > > or any other way to delay inserting? What precisely does this do? -- Richard Huxton Archonet Ltd
In article <14435275218.20050323193122@on.kg>, "ON.KG" <skyer@on.kg> writes: > Hi > Does PostgreSQL have something like "INSERT DELAYD" - like it is used in > MySQL? > or any other way to delay inserting? Every INSERT in PostgreSQL is delayed in some sense: firstly, it is not visible to anyone else until you commit, and secondly, it is written first to the (supposedly fast) write-ahead log and only later to the table files. If you have problems with INSERT speed, describe hardware, configuration, and table structure.
On Wed, 23 Mar 2005 14:50:47 +0000, Richard Huxton <dev@archonet.com> wrote: > ON.KG wrote: > > Hi > > > > Does PostgreSQL have something like "INSERT DELAYD" - like it is used in > > MySQL? > > > > or any other way to delay inserting? > > What precisely does this do? It adds an insert into a 'do this' queue and returns. From PostgreSQL-s point of view it would be equivalent of issuing INSERT and not waiting for the result. The MySQL has this mainly because when other statement such as SELECT or UPDATE is in progress, the INSERT would be blocked. PostgreSQL doesn't have such issues with blocking, so only difference between INSERT and INSERT DELAYED from PostgreSQL's standpoint would be waiting and not for the result...
Dawid Kuroczko wrote: > On Wed, 23 Mar 2005 14:50:47 +0000, Richard Huxton <dev@archonet.com> wrote: > >>ON.KG wrote: >> >>>Does PostgreSQL have something like "INSERT DELAYD" - like it is used in >>>MySQL? >>>or any other way to delay inserting? >> >>What precisely does this do? > > It adds an insert into a 'do this' queue and returns. From PostgreSQL-s > point of view it would be equivalent of issuing INSERT and not waiting > for the result. OK - thanks. > The MySQL has this mainly because when other statement such as > SELECT or UPDATE is in progress, the INSERT would be blocked. > > PostgreSQL doesn't have such issues with blocking, so only difference > between INSERT and INSERT DELAYED from PostgreSQL's standpoint > would be waiting and not for the result... Well, if you don't actually care whether it got inserted or not, just throw the data away! That's got to be the quickest of all. -- Richard Huxton Archonet Ltd
Dawid Kuroczko <qnex42@gmail.com> writes: > PostgreSQL doesn't have such issues with blocking, so only difference > between INSERT and INSERT DELAYED from PostgreSQL's standpoint > would be waiting and not for the result... An insert can be blocked if there's a UNIQUE constraint and another transaction has an insert or update pending for the same key. If the other transaction commits you get a unique constraint violation, if it aborts your insert succeeds. -- greg
Dawid Kuroczko <qnex42@gmail.com> writes:
> PostgreSQL doesn't have such issues with blocking, so only difference
> between INSERT and INSERT DELAYED from PostgreSQL's standpoint
> would be waiting and not for the result...
With the right client-side code you can transmit multiple queries before
receiving the result from the first one. I don't think libpq in its
current incarnation really supports this, but in principle it's doable.
The interesting questions have to do with error handling: if the
"delayed" insert fails, what happens and what is the impact on
subsequent queries? I have no idea how MySQL defines that.
regards, tom lane
On Wed, 23 Mar 2005 12:33:00 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dawid Kuroczko <qnex42@gmail.com> writes:
> > PostgreSQL doesn't have such issues with blocking, so only difference
> > between INSERT and INSERT DELAYED from PostgreSQL's standpoint
> > would be waiting and not for the result...
> With the right client-side code you can transmit multiple queries before
> receiving the result from the first one. I don't think libpq in its
> current incarnation really supports this, but in principle it's doable.
...though I think it should be called asynchronic rather than
'delayed'. I.e. issue a statement then select(2) in a spare
time to get the result, doing other work in meantime.
> The interesting questions have to do with error handling: if the
> "delayed" insert fails, what happens and what is the impact on
> subsequent queries? I have no idea how MySQL defines that.
Well, looking at the on-line mysql docs -- it is not documented,
I did however try to issue them (on 3.x mysql installation).
I've created a table with a single int PK column, then inserted
delayed few values, some of which broke PK contraint and these
were silently discared. There was no point checking how it would
work with transactions since ...delayed is MyISAM only and these
don't do transactions.
And as for PostgreSQL and asynchronic statements, I think it
should allow Pipelineing -- similar to NNTP or SMTP servers -- these would
send N commands to a server and then read them as-they-come-in.
Some usage example, imagine a web page which would:
$q1 = execute_async("SELECT foo FROM a");
$q2 = execute_async("SELECT * FROM polls LIMIT 5"); # whatever
$q3 = execute_async("SELECT baz FROM bazzz");
print some html; print $q1->fetchall, some html $q2->fetchall,
$q3->fetchall...
There is a question of synchronization and handling errors of course,
but I think it could be done and for some usage scenarios could be
quite benefitial.
Disclaimer: I never wrote a program using libpq, and I only looked
through libpq docs some time ago. If I am wrong, please forgive me.
Regards,
Dawid