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

Re: Optimising inside transactions

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: John Taylor <postgres(at)jtresponse(dot)co(dot)uk>
Cc: "PgSQL Novice" <pgsql-novice(at)postgresql(dot)org>
Subject: Re: Optimising inside transactions
Date: 2002-06-12 18:14:13
Message-ID: fl3fgu0b76dq1lje2knpvi155vgmmteef7@4ax.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-jdbcpgsql-novice
On Wed, 12 Jun 2002 16:07:26 +0100, John Taylor
<postgres(at)jtresponse(dot)co(dot)uk> wrote:
>
>Hi,
>
>I'm running a transaction with about 1600 INSERTs.
>Each INSERT involves a subselect.
>
>I've noticed that if one of the INSERTs fails, the remaining INSERTs run in about
>1/2 the time expected.
>
>Is postgresql optimising the inserts, knowing that it will rollback at the end ?
>
ISTM "optimising" is not the right word, it doesn't even try to
execute them.

fred=# BEGIN;
BEGIN
fred=# INSERT INTO a VALUES (1, 'x');
INSERT 174658 1
fred=# blabla;
ERROR:  parser: parse error at or near "blabla"
fred=# INSERT INTO a VALUES (2, 'y');
NOTICE:  current transaction is aborted, queries ignored until end of
transaction block
*ABORT STATE*
fred=# ROLLBACK;
ROLLBACK

Servus
 Manfred

In response to

pgsql-novice by date

Next:From: Andrew McMillanDate: 2002-06-13 12:46:05
Subject: Re: How efficient are Views
Previous:From: Tom LaneDate: 2002-06-12 16:12:50
Subject: Shouldn't "aborted transaction" be an ERROR? (was Re: [NOVICE] Optimising inside transactions)

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-06-12 18:23:16
Subject: Re: Number of attributes in HeapTupleHeader
Previous:From: Bruce MomjianDate: 2002-06-12 18:11:53
Subject: Re: a vulnerability in PostgreSQL

pgsql-jdbc by date

Next:From: Steve KirbyDate: 2002-06-12 23:36:31
Subject: lo_import
Previous:From: Tom LaneDate: 2002-06-12 16:12:50
Subject: Shouldn't "aborted transaction" be an ERROR? (was Re: [NOVICE] Optimising inside transactions)

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