On L, 2005-03-12 at 14:05 -0800, Josh Berkus wrote:
Tambet,
In one of our applications we have a database function, which
recalculates COGS (cost of good sold) for certain period. This involves
deleting bunch of rows from one table, inserting them again in correct
order and updating
--
Date: Mon, 14 Mar 2005 09:41:30 +0800
From: Qingqing Zhou [EMAIL PROTECTED]
To: pgsql-performance@postgresql.org
Subject: Re: One tuple per transaction
Message-ID: [EMAIL PROTECTED]
Tambet Matiisen [EMAIL PROTECTED] writes
...
If I'm correct, the dead
Tambet Matiisen wrote:
Not exactly. The dead tuple in the index will be scanned the
first time (and its pointed heap tuple as well), then we will
mark it dead, then next time we came here, we will know that
the index tuple actually points to a uesless tuple, so we
will not scan its pointed
-Original Message-
From: Richard Huxton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 15, 2005 11:38 AM
To: Tambet Matiisen
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] One tuple per transaction
...
Consider the often suggested solution for speeding up
On Tuesday 15 March 2005 04:37, Richard Huxton wrote:
Tambet Matiisen wrote:
Now, if typical inserts into your most active table occur in batches of
3 rows, in one transaction, then row count for this table is updated 3
times during transaction. 3 updates generate 3 tuples, while 2 of them
Robert Treat [EMAIL PROTECTED] writes:
On a similar note I was just wondering if it would be possible to
mark any of these dead tuples as ready to be reused at transaction
commit time, since we know that they are dead to any and all other
transactions currently going on.
I believe VACUUM
On Tue, Mar 15, 2005 at 06:51:19PM -0500, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On a similar note I was just wondering if it would be possible to
mark any of these dead tuples as ready to be reused at transaction
commit time, since we know that they are dead to any and all
Alvaro Herrera [EMAIL PROTECTED] writes:
On Tue, Mar 15, 2005 at 06:51:19PM -0500, Tom Lane wrote:
I believe VACUUM already knows that xmin = xmax implies the tuple
is dead to everyone.
Huh, that is too simplistic in a subtransactions' world, isn't it?
Well, it's still correct as a fast-path
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 13, 2005 12:05 AM
To: Tambet Matiisen
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] One tuple per transaction
Tambet,
In one of our applications we have a database function
Tambet Matiisen [EMAIL PROTECTED] writes
Hi!
In one of our applications we have a database function, which
recalculates COGS (cost of good sold) for certain period. This involves
deleting bunch of rows from one table, inserting them again in correct
order and updating them one-by-one
Tambet,
In one of our applications we have a database function, which
recalculates COGS (cost of good sold) for certain period. This involves
deleting bunch of rows from one table, inserting them again in correct
order and updating them one-by-one (sometimes one row twice) to reflect
current
11 matches
Mail list logo
