postgresql/src/backend/utils/time/tqual.c

254 lines
7.1 KiB
C
Raw Normal View History

/*-------------------------------------------------------------------------
*
* tqual.c--
1997-11-02 16:27:14 +01:00
* POSTGRES "time" qualification code.
*
* Copyright (c) 1994, Regents of the University of California
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/utils/time/tqual.c,v 1.19 1998/09/01 04:33:41 momjian Exp $
*
*-------------------------------------------------------------------------
*/
/* #define TQUALDEBUG 1 */
#include "postgres.h"
#include "access/htup.h"
#include "access/xact.h"
#include "storage/bufmgr.h"
#include "access/transam.h"
#include "utils/elog.h"
#include "utils/palloc.h"
#include "utils/tqual.h"
extern bool PostgresIsInitialized;
/*
* XXX Transaction system override hacks start here
*/
#ifndef GOODAMI
TransactionId HeapSpecialTransactionId = InvalidTransactionId;
CommandId HeapSpecialCommandId = FirstCommandId;
void
setheapoverride(bool on)
{
if (on)
{
TransactionIdStore(GetCurrentTransactionId(),
&HeapSpecialTransactionId);
HeapSpecialCommandId = GetCurrentCommandId();
}
else
HeapSpecialTransactionId = InvalidTransactionId;
}
#endif /* !defined(GOODAMI) */
/*
* XXX Transaction system override hacks end here
*/
/*
* HeapTupleSatisfiesItself --
* True iff heap tuple is valid for "itself."
* "{it}self" means valid as of everything that's happened
* in the current transaction, _including_ the current command.
*
* Note:
* Assumes heap tuple is valid.
*/
/*
* The satisfaction of "itself" requires the following:
*
* ((Xmin == my-transaction && the row was updated by the current transaction, and
* (Xmax is null it was not deleted
* [|| Xmax != my-transaction)]) [or it was deleted by another transaction]
* ||
*
* (Xmin is committed && the row was modified by a committed transaction, and
* (Xmax is null || the row has not been deleted, or
* (Xmax != my-transaction && the row was deleted by another transaction
* Xmax is not committed))) that has not been committed
*/
bool
HeapTupleSatisfiesItself(HeapTuple tuple)
{
From: Dan McGuirk <mcguirk@indirect.com> Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com> To: hackers@hub.org Subject: [HACKERS] tmin writeback optimization I was doing some profiling of the backend, and noticed that during a certain benchmark I was running somewhere between 30% and 75% of the backend's CPU time was being spent in calls to TransactionIdDidCommit() from HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that changed rows' transactions had in fact been committed even though the rows' tmin values had not yet been set. When a query looks at a given row, it needs to figure out whether the transaction that changed the row has been committed and hence it should pay attention to the row, or whether on the other hand the transaction is still in progress or has been aborted and hence the row should be ignored. If a tmin value is set, it is known definitively that the row's transaction has been committed. However, if tmin is not set, the transaction referred to in xmin must be looked up in pg_log, and this is what the backend was spending a lot of time doing during my benchmark. So, implementing a method suggested by Vadim, I created the following patch that, the first time a query finds a committed row whose tmin value is not set, sets it, and marks the buffer where the row is stored as dirty. (It works for tmax, too.) This doesn't result in the boost in real time performance I was hoping for, however it does decrease backend CPU usage by up to two-thirds in certain situations, so it could be rather beneficial in high-concurrency settings.
1997-03-28 08:06:53 +01:00
1997-11-02 16:27:14 +01:00
if (!(tuple->t_infomask & HEAP_XMIN_COMMITTED))
{
if (tuple->t_infomask & HEAP_XMIN_INVALID) /* xid invalid or
* aborted */
1998-09-01 05:29:17 +02:00
return false;
1997-11-02 16:27:14 +01:00
if (TransactionIdIsCurrentTransactionId(tuple->t_xmin))
{
1997-11-02 16:27:14 +01:00
if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid */
1998-09-01 05:29:17 +02:00
return true;
1997-11-02 16:27:14 +01:00
else
1998-09-01 05:29:17 +02:00
return false;
}
1997-11-02 16:27:14 +01:00
if (!TransactionIdDidCommit(tuple->t_xmin))
{
1997-11-02 16:27:14 +01:00
if (TransactionIdDidAbort(tuple->t_xmin))
tuple->t_infomask |= HEAP_XMIN_INVALID; /* aborted */
1998-09-01 05:29:17 +02:00
return false;
}
1997-11-02 16:27:14 +01:00
tuple->t_infomask |= HEAP_XMIN_COMMITTED;
}
/* the tuple was inserted validly */
From: Dan McGuirk <mcguirk@indirect.com> Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com> To: hackers@hub.org Subject: [HACKERS] tmin writeback optimization I was doing some profiling of the backend, and noticed that during a certain benchmark I was running somewhere between 30% and 75% of the backend's CPU time was being spent in calls to TransactionIdDidCommit() from HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that changed rows' transactions had in fact been committed even though the rows' tmin values had not yet been set. When a query looks at a given row, it needs to figure out whether the transaction that changed the row has been committed and hence it should pay attention to the row, or whether on the other hand the transaction is still in progress or has been aborted and hence the row should be ignored. If a tmin value is set, it is known definitively that the row's transaction has been committed. However, if tmin is not set, the transaction referred to in xmin must be looked up in pg_log, and this is what the backend was spending a lot of time doing during my benchmark. So, implementing a method suggested by Vadim, I created the following patch that, the first time a query finds a committed row whose tmin value is not set, sets it, and marks the buffer where the row is stored as dirty. (It works for tmax, too.) This doesn't result in the boost in real time performance I was hoping for, however it does decrease backend CPU usage by up to two-thirds in certain situations, so it could be rather beneficial in high-concurrency settings.
1997-03-28 08:06:53 +01:00
1997-11-02 16:27:14 +01:00
if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid or aborted */
1998-09-01 05:29:17 +02:00
return true;
1997-11-02 16:27:14 +01:00
if (tuple->t_infomask & HEAP_XMAX_COMMITTED)
1998-09-01 05:29:17 +02:00
return false;
1997-11-02 16:27:14 +01:00
if (TransactionIdIsCurrentTransactionId(tuple->t_xmax))
1998-09-01 05:29:17 +02:00
return false;
1997-11-02 16:27:14 +01:00
if (!TransactionIdDidCommit(tuple->t_xmax))
{
1997-11-02 16:27:14 +01:00
if (TransactionIdDidAbort(tuple->t_xmax))
tuple->t_infomask |= HEAP_XMAX_INVALID; /* aborted */
1998-09-01 05:29:17 +02:00
return true;
}
/* by here, deleting transaction has committed */
1997-11-02 16:27:14 +01:00
tuple->t_infomask |= HEAP_XMAX_COMMITTED;
1998-09-01 05:29:17 +02:00
return false;
}
/*
* HeapTupleSatisfiesNow --
* True iff heap tuple is valid "now."
* "now" means valid including everything that's happened
* in the current transaction _up to, but not including,_
* the current command.
*
* Note:
* Assumes heap tuple is valid.
*/
/*
* The satisfaction of "now" requires the following:
*
* ((Xmin == my-transaction && changed by the current transaction
* Cmin != my-command && but not by this command, and
* (Xmax is null || the row has not been deleted, or
* (Xmax == my-transaction && it was deleted by the current transaction
* Cmax != my-command))) but not by this command,
* || or
*
* (Xmin is committed && the row was modified by a committed transaction, and
* (Xmax is null || the row has not been deleted, or
* (Xmax == my-transaction && the row is being deleted by this command, or
* Cmax == my-command) ||
* (Xmax is not committed && the row was deleted by another transaction
* Xmax != my-transaction)))) that has not been committed
*
* XXX
* CommandId stuff didn't work properly if one used SQL-functions in
* UPDATE/INSERT(fromSELECT)/DELETE scans: SQL-funcs call
* CommandCounterIncrement and made tuples changed/inserted by
* current command visible to command itself (so we had multiple
* update of updated tuples, etc). - vadim 08/29/97
*
* mao says 17 march 1993: the tests in this routine are correct;
* if you think they're not, you're wrong, and you should think
* about it again. i know, it happened to me. we don't need to
* check commit time against the start time of this transaction
* because 2ph locking protects us from doing the wrong thing.
* if you mess around here, you'll break serializability. the only
* problem with this code is that it does the wrong thing for system
* catalog updates, because the catalogs aren't subject to 2ph, so
* the serializability guarantees we provide don't extend to xacts
* that do catalog accesses. this is unfortunate, but not critical.
*/
bool
HeapTupleSatisfiesNow(HeapTuple tuple)
{
if (AMI_OVERRIDE)
return true;
/*
* If the transaction system isn't yet initialized, then we assume
* that transactions committed. We only look at system catalogs
* during startup, so this is less awful than it seems, but it's still
* pretty awful.
*/
From: Dan McGuirk <mcguirk@indirect.com> Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com> To: hackers@hub.org Subject: [HACKERS] tmin writeback optimization I was doing some profiling of the backend, and noticed that during a certain benchmark I was running somewhere between 30% and 75% of the backend's CPU time was being spent in calls to TransactionIdDidCommit() from HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that changed rows' transactions had in fact been committed even though the rows' tmin values had not yet been set. When a query looks at a given row, it needs to figure out whether the transaction that changed the row has been committed and hence it should pay attention to the row, or whether on the other hand the transaction is still in progress or has been aborted and hence the row should be ignored. If a tmin value is set, it is known definitively that the row's transaction has been committed. However, if tmin is not set, the transaction referred to in xmin must be looked up in pg_log, and this is what the backend was spending a lot of time doing during my benchmark. So, implementing a method suggested by Vadim, I created the following patch that, the first time a query finds a committed row whose tmin value is not set, sets it, and marks the buffer where the row is stored as dirty. (It works for tmax, too.) This doesn't result in the boost in real time performance I was hoping for, however it does decrease backend CPU usage by up to two-thirds in certain situations, so it could be rather beneficial in high-concurrency settings.
1997-03-28 08:06:53 +01:00
if (!PostgresIsInitialized)
1997-11-02 16:27:14 +01:00
return ((bool) (TransactionIdIsValid(tuple->t_xmin) &&
!TransactionIdIsValid(tuple->t_xmax)));
1997-11-02 16:27:14 +01:00
if (!(tuple->t_infomask & HEAP_XMIN_COMMITTED))
{
if (tuple->t_infomask & HEAP_XMIN_INVALID) /* xid invalid or
* aborted */
1998-09-01 05:29:17 +02:00
return false;
1997-11-02 16:27:14 +01:00
if (TransactionIdIsCurrentTransactionId(tuple->t_xmin))
{
1997-11-02 16:27:14 +01:00
if (CommandIdGEScanCommandId(tuple->t_cmin))
return false; /* inserted after scan started */
1997-11-02 16:27:14 +01:00
if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid */
1998-09-01 05:29:17 +02:00
return true;
1997-11-02 16:27:14 +01:00
Assert(TransactionIdIsCurrentTransactionId(tuple->t_xmax));
if (CommandIdGEScanCommandId(tuple->t_cmax))
1998-09-01 05:29:17 +02:00
return true; /* deleted after scan started */
1997-11-02 16:27:14 +01:00
else
return false; /* deleted before scan started */
}
/*
* this call is VERY expensive - requires a log table lookup.
*/
1997-11-02 16:27:14 +01:00
if (!TransactionIdDidCommit(tuple->t_xmin))
{
1997-11-02 16:27:14 +01:00
if (TransactionIdDidAbort(tuple->t_xmin))
tuple->t_infomask |= HEAP_XMIN_INVALID; /* aborted */
1998-09-01 05:29:17 +02:00
return false;
}
1997-11-02 16:27:14 +01:00
tuple->t_infomask |= HEAP_XMIN_COMMITTED;
}
From: Dan McGuirk <mcguirk@indirect.com> Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com> To: hackers@hub.org Subject: [HACKERS] tmin writeback optimization I was doing some profiling of the backend, and noticed that during a certain benchmark I was running somewhere between 30% and 75% of the backend's CPU time was being spent in calls to TransactionIdDidCommit() from HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that changed rows' transactions had in fact been committed even though the rows' tmin values had not yet been set. When a query looks at a given row, it needs to figure out whether the transaction that changed the row has been committed and hence it should pay attention to the row, or whether on the other hand the transaction is still in progress or has been aborted and hence the row should be ignored. If a tmin value is set, it is known definitively that the row's transaction has been committed. However, if tmin is not set, the transaction referred to in xmin must be looked up in pg_log, and this is what the backend was spending a lot of time doing during my benchmark. So, implementing a method suggested by Vadim, I created the following patch that, the first time a query finds a committed row whose tmin value is not set, sets it, and marks the buffer where the row is stored as dirty. (It works for tmax, too.) This doesn't result in the boost in real time performance I was hoping for, however it does decrease backend CPU usage by up to two-thirds in certain situations, so it could be rather beneficial in high-concurrency settings.
1997-03-28 08:06:53 +01:00
/* by here, the inserting transaction has committed */
From: Dan McGuirk <mcguirk@indirect.com> Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com> To: hackers@hub.org Subject: [HACKERS] tmin writeback optimization I was doing some profiling of the backend, and noticed that during a certain benchmark I was running somewhere between 30% and 75% of the backend's CPU time was being spent in calls to TransactionIdDidCommit() from HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that changed rows' transactions had in fact been committed even though the rows' tmin values had not yet been set. When a query looks at a given row, it needs to figure out whether the transaction that changed the row has been committed and hence it should pay attention to the row, or whether on the other hand the transaction is still in progress or has been aborted and hence the row should be ignored. If a tmin value is set, it is known definitively that the row's transaction has been committed. However, if tmin is not set, the transaction referred to in xmin must be looked up in pg_log, and this is what the backend was spending a lot of time doing during my benchmark. So, implementing a method suggested by Vadim, I created the following patch that, the first time a query finds a committed row whose tmin value is not set, sets it, and marks the buffer where the row is stored as dirty. (It works for tmax, too.) This doesn't result in the boost in real time performance I was hoping for, however it does decrease backend CPU usage by up to two-thirds in certain situations, so it could be rather beneficial in high-concurrency settings.
1997-03-28 08:06:53 +01:00
1997-11-02 16:27:14 +01:00
if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid or aborted */
1998-09-01 05:29:17 +02:00
return true;
1997-11-02 16:27:14 +01:00
if (tuple->t_infomask & HEAP_XMAX_COMMITTED)
1998-09-01 05:29:17 +02:00
return false;
1997-11-02 16:27:14 +01:00
if (TransactionIdIsCurrentTransactionId(tuple->t_xmax))
{
1997-11-02 16:27:14 +01:00
if (CommandIdGEScanCommandId(tuple->t_cmax))
1998-09-01 05:29:17 +02:00
return true; /* deleted after scan started */
1997-11-02 16:27:14 +01:00
else
1998-09-01 05:29:17 +02:00
return false; /* deleted before scan started */
}
1997-11-02 16:27:14 +01:00
if (!TransactionIdDidCommit(tuple->t_xmax))
{
1997-11-02 16:27:14 +01:00
if (TransactionIdDidAbort(tuple->t_xmax))
tuple->t_infomask |= HEAP_XMAX_INVALID; /* aborted */
1998-09-01 05:29:17 +02:00
return true;
}
1997-11-02 16:27:14 +01:00
/* xmax transaction committed */
tuple->t_infomask |= HEAP_XMAX_COMMITTED;
1998-09-01 05:29:17 +02:00
return false;
}