Обсуждение: 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?

ServusManfred

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.

ServusManfred

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