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 upd
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 fa
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
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 VACUU
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
> -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 s
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 heap
> --
>
> 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'
""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-
> -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
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
> cur
11 matches
Mail list logo
