Heap tuple header issues
On Mon, 05 Aug 2002 10:06:37 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
I've refrained from touching the tuple-header issues until Manfred
returns from vacation and can defend himself ;-)
En garde! Seriously, I don't think I have to defend *myself*, because
I'm not going to be attacked personally. I'm ready to discuss,
defend, and/or drop my work ...
. Transaction and command ids, performance
I offered to provide cheaper versions of GetCmin and GetCmax to be
used by the tqual routines. These version would reduce additional CPU
work from two infomask compares to one. Is this still considered an
issue?
. Transaction and command ids, robustness
I'm still of the opinion that putting *more* knowledge into the SetXxx
macros is the way to go. The runaway INSERT bug could as well have
been fixed by changing SetCmax to do nothing, if HEAP_XMAX_INVALID is
set, and changing SetXmaxInvalid to set HEAP_XMAX_INVALID. Likewise I
would change SetXmax to set HEAP_XMAX_INVALID, if xid ==
InvalidTransactionId, or reset it, if != (not sure about this). Same
for SetXminInvalid and SetXmin.
Further, I'll try to build a regression test using statement timeout
to detect runaway INSERT/UPDATE (the so called "halloween" problem).
. Oids
I was a bit surprised that these patches went in so smoothly, must be
due to the fact that there was a lot of work to do at that time.
Personnally I feel that these changes are more dangerous than the
Xmin/Cid/Xmax patches; and I ask the hackers to review especially
part 2, which contains changes to the executor and even to bootstrap.
. Oids, t_infomask
There has been no comment from a tool developer.
. Oids, heap_getsysattr
We thought that a TupleDesc parameter would have to be added for this
function. However, tests showed that heap_getsysattr is not called to
get the oid, when the tuple doesn't have an oid: "ERROR: Attribute
'oid' not found".
. Oids, micro tuning
There are a few places, where storing an oid in a local variable might
be a little faster than fetching it several times from a heap tuple
header.
. Overall performance
If Joe Conway can be talked into running OSDB benchmarks with old and
new heap tuple header format, I'll provide patches and instructions to
easily switch between versions. Or, Joe, can you tell me, what I need
to have and need to do to set up a benchmarking environment?
. CVS
There have been a lot of "CVS broken" messages in the past few days.
When I tried
cvs -z3 log heapam.c
I got
| cvs server: failed to create lock directory for `/projects/cvsroot/pgsql/src/backend/access/heap' (/projects/cvsroot/pgsql/src/backend/access/heap/#cvs.lock): No such file or directory
| cvs server: failed to obtain dir lock in repository `/projects/cvsroot/pgsql/src/backend/access/heap'
| cvs [server aborted]: read lock failed - giving up
Is this a temporary problem or did a miss any planned changes?
Servus
Manfred
Manfred Koizar wrote:
. Overall performance
If Joe Conway can be talked into running OSDB benchmarks with old and
new heap tuple header format, I'll provide patches and instructions to
easily switch between versions. Or, Joe, can you tell me, what I need
to have and need to do to set up a benchmarking environment?
I just grabbed a copy and followed the instructions as found on
sourceforge. Just search on OSDB. Get the source tarball and the 40MB
test dataset.
I guess I could be talked into running some more tests, but they take a
few hours of run time for each iteration, during which I can't use my
dev machine (at least if I don't want to affect the results), so it's a
bit of a pain.
We should probably coordinate off-list and then just report back the
results.
Joe
On Wed, 07 Aug 2002 08:51:08 -0700, Joe Conway <mail@joeconway.com>
wrote:
I just grabbed a copy and followed the instructions as found on
sourceforge. Just search on OSDB. Get the source tarball and the 40MB
test dataset.
Nothing special for PG? That's good news. I imagined there was some
tweaking necessary; don't remember where I got that impression from.
Download started.
I guess I could be talked into running some more tests
If I cannot get reliable results out of my slow old development
machine, I'll come back to you. Thanks.
Servus
Manfred
Manfred Koizar wrote:
On Wed, 07 Aug 2002 08:51:08 -0700, Joe Conway <mail@joeconway.com>
wrote:I just grabbed a copy and followed the instructions as found on
sourceforge. Just search on OSDB. Get the source tarball and the 40MB
test dataset.Nothing special for PG? That's good news. I imagined there was some
tweaking necessary; don't remember where I got that impression from.
Download started.
I only needed to do:
./configure --with-postgresql=/usr/local/pgsql
make
make install
and then
osdb-pg --datadir /opt/src/osdb/data --postgresql=no_hash_index
If I cannot get reliable results out of my slow old development
machine, I'll come back to you. Thanks.
IIRC the test takes 2 to 3 hours on my development machine which is a
1GHz Athlon, 512MB RAM, 7200 rpm IDE drives. If it becomes a problem for
you, let me know.
Joe