From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: HOT is applied |
Date: | 2007-09-21 15:22:17 |
Message-ID: | 5424.1190388137@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> If you look at the callgraph, you'll see that those
> LWLockAcquire/Release calls are coming from HeapTupleSatisfiesVacuum ->
> TransactionIdIsInProgress, which keeps trashing the ProcArrayLock. A
> "if(TransactionIdIsCurrentTransactionId(xid)) return true;" check in
> TransactionIdIsInProgress would speed that up, but I wonder if there's a
> more general solution to make HeapTupleSatisfiesVacuum cheaper. For
> example, we could cache the in-progress status of tuples.
Dunno about "more general", but your idea reduces the runtime of this
example by about 50% (22.2s to 10.5s) for me. I'm worried though that
it would be a net negative in more typical situations, especially if
you've got a lot of open subtransactions.
regards, tom lane
*** src/backend/storage/ipc/procarray.c.orig Sat Sep 8 16:31:15 2007
--- src/backend/storage/ipc/procarray.c Fri Sep 21 11:08:34 2007
***************
*** 341,346 ****
--- 341,353 ----
return false;
}
+ /*
+ * Also, we can detect our own transaction without any access to shared
+ * memory.
+ */
+ if (TransactionIdIsCurrentTransactionId(xid))
+ return true;
+
/* Get workspace to remember main XIDs in */
xids = (TransactionId *) palloc(sizeof(TransactionId) * arrayP->maxProcs);
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-21 16:25:51 | Re: Schema access in PL/PGSQL for custom objects - i.e. type access? |
Previous Message | Heikki Linnakangas | 2007-09-21 15:17:50 | Re: HOT is applied |