mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-22 07:53:22 +02:00
1071 lines
40 KiB
Plaintext
1071 lines
40 KiB
Plaintext
From pgsql-hackers-owner+M18800=candle.pha.pa.us=pgman@postgresql.org Wed Feb 13 15:25:43 2002
|
||
Return-path: <pgsql-hackers-owner+M18800=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1DKPgP09129
|
||
for <pgman@candle.pha.pa.us>; Wed, 13 Feb 2002 15:25:42 -0500 (EST)
|
||
Received: (qmail 83025 invoked by alias); 13 Feb 2002 20:25:41 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 13 Feb 2002 20:25:41 -0000
|
||
Received: from h97.c194.tor.velocet.net (H97.C194.tor.velocet.net [216.138.194.97])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g1DK7kE77269
|
||
for <pgsql-hackers@postgresql.org>; Wed, 13 Feb 2002 15:07:47 -0500 (EST)
|
||
(envelope-from rbt@zort.ca)
|
||
Received: (qmail 41141 invoked by uid 0); 13 Feb 2002 20:07:41 -0000
|
||
Received: from h97.c194.tor.velocet.net (HELO jester) (216.138.194.97)
|
||
by 192.168.1.11 with RC4-MD5 encrypted SMTP; 13 Feb 2002 20:07:41 -0000
|
||
Message-ID: <003901c1b4ca$1d762500$8001a8c0@jester>
|
||
From: "Rod Taylor" <rbt@zort.ca>
|
||
To: "Hackers List" <pgsql-hackers@postgresql.org>
|
||
Subject: [HACKERS] NAMEDATALEN Changes
|
||
Date: Wed, 13 Feb 2002 15:07:50 -0500
|
||
MIME-Version: 1.0
|
||
Content-Type: multipart/mixed;
|
||
boundary="----=_NextPart_000_0036_01C1B4A0.343E4DF0"
|
||
X-Priority: 3
|
||
X-MSMail-Priority: Normal
|
||
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
|
||
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
This is a multi-part message in MIME format.
|
||
|
||
------=_NextPart_000_0036_01C1B4A0.343E4DF0
|
||
Content-Type: text/plain; charset="iso-8859-1"
|
||
Content-Transfer-Encoding: 7bit
|
||
|
||
NAMEDATALEN's benchmarked are 32, 64, 128 and 512. Attached is the
|
||
shell script I used to do it.
|
||
|
||
First row of a set is the time(1) for the pgbench -i run, second is
|
||
the actual benchmark. Aside from the 'real' time of 64 there is a
|
||
distinct increase in time required, but not significant.
|
||
|
||
Benchmarks were run for 3000 transactions with scale factor of 5, but
|
||
only 1 client. If there is a preferred setting for pgbench I can do
|
||
an overnight run with it. Machine is a dual 500Mhz celery with 384MB
|
||
ram and 2 IBM Deskstars in Raid 0, and a seperate system drive.
|
||
|
||
Anything but 32 fails the 'name' check in the regression tests -- I
|
||
assume this is expected?
|
||
|
||
Don't know why 64 has a high 'real' time, but the system times are
|
||
appropriate.
|
||
|
||
NAMEDATALEN: 32
|
||
|
||
158.97 real 1.81 user 0.14 sys
|
||
|
||
80.58 real 1.30 user 3.81 sys
|
||
|
||
|
||
|
||
NAMEDATALEN: 64
|
||
|
||
248.40 real 1.85 user 0.10 sys
|
||
|
||
96.36 real 1.44 user 3.86 sys
|
||
|
||
|
||
|
||
NAMEDATALEN: 128
|
||
|
||
156.74 real 1.84 user 0.10 sys
|
||
|
||
94.36 real 1.47 user 4.01 sys
|
||
|
||
|
||
|
||
NAMEDATALEN: 512
|
||
|
||
157.99 real 1.83 user 0.12 sys
|
||
|
||
101.14 real 1.47 user 4.23 sys
|
||
|
||
--
|
||
Rod Taylor
|
||
|
||
Your eyes are weary from staring at the CRT. You feel sleepy. Notice
|
||
how restful it is to watch the cursor blink. Close your eyes. The
|
||
opinions stated above are yours. You cannot imagine why you ever felt
|
||
otherwise.
|
||
|
||
|
||
------=_NextPart_000_0036_01C1B4A0.343E4DF0
|
||
Content-Type: application/octet-stream; name="datalenbench.sh"
|
||
Content-Transfer-Encoding: quoted-printable
|
||
Content-Disposition: attachment; filename="datalenbench.sh"
|
||
|
||
#!/bin/sh
|
||
|
||
PGSRC=3D/data/buildtree/postgres/postgresql-7.2
|
||
PGBASEPORT=3D5400
|
||
PGBASEBIN=3D/data/buildtree/postgres/postgres72
|
||
|
||
LOG=3D/home/rbt/temp/bench_namedatalen.log
|
||
|
||
|
||
for newDATALEN in 32 64 128 512 ; do
|
||
|
||
PGBIN=3D${PGBASEBIN}_${newDATALEN}
|
||
PGPORT=3D`echo "${PGBASEPORT}+${newDATALEN}" | bc`
|
||
|
||
sed -E 's/NAMEDATALEN\s[0-9]+/NAMEDATALEN ${newDATALEN}/g' ${PGSRC}/src/i=
|
||
nclude/postgres_ext.h > ${PGSRC}/src/include/postgres_ext.h.tmp
|
||
mv ${PGSRC}/src/include/postgres_ext.h.tmp ${PGSRC}/src/include/postgres_=
|
||
ext.h
|
||
|
||
cd ${PGSRC}
|
||
./configure --prefix=3D${PGBIN} --with-pgport=3D${PGPORT} || (echo "UNABL=
|
||
E TO CONFIGURE"; exit)
|
||
|
||
make clean
|
||
make clean install
|
||
|
||
cd ${PGSRC}/contrib/pgbench
|
||
|
||
gmake install
|
||
|
||
|
||
${PGBIN}/bin/initdb -D ${PGBIN}/data || (echo "UNABLE TO INITIALIZE"; ex=
|
||
it 1)
|
||
|
||
${PGBIN}/bin/pg_ctl -D ${PGBIN}/data start || (echo "UNABLE TO START"; e=
|
||
xit 1)
|
||
|
||
sleep 5
|
||
|
||
echo "NAMEDATALEN: ${newDATALEN}" >> ${LOG}
|
||
echo >> ${LOG}
|
||
time -a -o ${LOG} ${PGBIN}/bin/pgbench -i -s 5 -d template1 -p ${PGPORT}
|
||
|
||
time -a -o ${LOG} ${PGBIN}/bin/pgbench -t 3000 -s 5 -d template1 -p ${PGP=
|
||
ORT}
|
||
echo >> ${LOG}
|
||
echo >> ${LOG}
|
||
|
||
${PGBIN}/bin/pg_ctl -D ${PGBIN}/data stop
|
||
rm -rf ${PGBIN}
|
||
done
|
||
|
||
------=_NextPart_000_0036_01C1B4A0.343E4DF0
|
||
Content-Type: text/plain
|
||
Content-Disposition: inline
|
||
Content-Transfer-Encoding: binary
|
||
MIME-Version: 1.0
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
------=_NextPart_000_0036_01C1B4A0.343E4DF0--
|
||
|
||
|
||
From pgsql-hackers-owner+M18806=candle.pha.pa.us=pgman@postgresql.org Wed Feb 13 17:13:45 2002
|
||
Return-path: <pgsql-hackers-owner+M18806=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1DMDiP15852
|
||
for <pgman@candle.pha.pa.us>; Wed, 13 Feb 2002 17:13:44 -0500 (EST)
|
||
Received: (qmail 13525 invoked by alias); 13 Feb 2002 22:12:53 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 13 Feb 2002 22:12:53 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g1DLsHE09337
|
||
for <pgsql-hackers@postgresql.org>; Wed, 13 Feb 2002 16:54:17 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g1DLrmf00943;
|
||
Wed, 13 Feb 2002 16:53:49 -0500 (EST)
|
||
To: "Rod Taylor" <rbt@zort.ca>
|
||
cc: "Hackers List" <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] NAMEDATALEN Changes
|
||
In-Reply-To: <003901c1b4ca$1d762500$8001a8c0@jester>
|
||
References: <003901c1b4ca$1d762500$8001a8c0@jester>
|
||
Comments: In-reply-to "Rod Taylor" <rbt@zort.ca>
|
||
message dated "Wed, 13 Feb 2002 15:07:50 -0500"
|
||
Date: Wed, 13 Feb 2002 16:53:48 -0500
|
||
Message-ID: <940.1013637228@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
"Rod Taylor" <rbt@zort.ca> writes:
|
||
> [ some hard data ]
|
||
|
||
Great! The numbers for namedatalen = 64 seem like an outlier; perhaps
|
||
something else going on on your system? Did you try more than one run?
|
||
|
||
> Anything but 32 fails the 'name' check in the regression tests -- I
|
||
> assume this is expected?
|
||
|
||
Right. If you eyeball the actual diffs for the test you should see that
|
||
the diff is due to a long name not getting truncated where the test
|
||
expects it to be.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18805=candle.pha.pa.us=pgman@postgresql.org Wed Feb 13 17:13:39 2002
|
||
Return-path: <pgsql-hackers-owner+M18805=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1DMDcP15802
|
||
for <pgman@candle.pha.pa.us>; Wed, 13 Feb 2002 17:13:39 -0500 (EST)
|
||
Received: (qmail 13545 invoked by alias); 13 Feb 2002 22:12:54 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 13 Feb 2002 22:12:54 -0000
|
||
Received: from h97.c194.tor.velocet.net (H97.C194.tor.velocet.net [216.138.194.97])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g1DM7iE12735
|
||
for <pgsql-hackers@postgresql.org>; Wed, 13 Feb 2002 17:07:44 -0500 (EST)
|
||
(envelope-from rbt@zort.ca)
|
||
Received: (qmail 41562 invoked by uid 0); 13 Feb 2002 22:07:45 -0000
|
||
Received: from h97.c194.tor.velocet.net (HELO jester) (216.138.194.97)
|
||
by 192.168.1.11 with RC4-MD5 encrypted SMTP; 13 Feb 2002 22:07:45 -0000
|
||
Message-ID: <00f501c1b4da$e2f7b7c0$8001a8c0@jester>
|
||
From: "Rod Taylor" <rbt@zort.ca>
|
||
To: "Tom Lane" <tgl@sss.pgh.pa.us>
|
||
cc: "Hackers List" <pgsql-hackers@postgresql.org>
|
||
References: <003901c1b4ca$1d762500$8001a8c0@jester> <940.1013637228@sss.pgh.pa.us>
|
||
Subject: Re: [HACKERS] NAMEDATALEN Changes
|
||
Date: Wed, 13 Feb 2002 17:07:54 -0500
|
||
MIME-Version: 1.0
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
Content-Transfer-Encoding: 7bit
|
||
X-Priority: 3
|
||
X-MSMail-Priority: Normal
|
||
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
|
||
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
> > Great! The numbers for namedatalen = 64 seem like an outlier;
|
||
perhaps
|
||
> something else going on on your system? Did you try more than one
|
||
run?
|
||
|
||
Ran it again shortly after sending the email. It fell in line (mid
|
||
way between 32 and 128) with Real time as would normally be expected.
|
||
The times for the other values and 64's system times were very close
|
||
to the original so I won't bother posting them again.
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M18807=candle.pha.pa.us=pgman@postgresql.org Wed Feb 13 17:58:53 2002
|
||
Return-path: <pgsql-hackers-owner+M18807=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1DMwqP19126
|
||
for <pgman@candle.pha.pa.us>; Wed, 13 Feb 2002 17:58:52 -0500 (EST)
|
||
Received: (qmail 26752 invoked by alias); 13 Feb 2002 22:58:21 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 13 Feb 2002 22:58:21 -0000
|
||
Received: from post.webmailer.de (natwar.webmailer.de [192.67.198.70])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g1DMRoE22486
|
||
for <pgsql-hackers@postgresql.org>; Wed, 13 Feb 2002 17:27:51 -0500 (EST)
|
||
(envelope-from barwick@gmx.net)
|
||
Received: from there (pD9EB1E9E.dip.t-dialin.net [217.235.30.158])
|
||
by post.webmailer.de (8.9.3/8.8.7) with SMTP id XAA22201;
|
||
Wed, 13 Feb 2002 23:27:16 +0100 (MET)
|
||
Message-ID: <200202132227.XAA22201@post.webmailer.de>
|
||
From: Ian Barwick <barwick@gmx.net>
|
||
To: "Rod Taylor" <rbt@zort.ca>, "Hackers List" <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] NAMEDATALEN Changes
|
||
Date: Wed, 13 Feb 2002 23:27:08 +0100
|
||
X-Mailer: KMail [version 1.3.1]
|
||
References: <003901c1b4ca$1d762500$8001a8c0@jester>
|
||
In-Reply-To: <003901c1b4ca$1d762500$8001a8c0@jester>
|
||
MIME-Version: 1.0
|
||
Content-Type: Multipart/Mixed;
|
||
boundary="------------Boundary-00=_81THUZ3BONDS8SCE1A8O"
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
--------------Boundary-00=_81THUZ3BONDS8SCE1A8O
|
||
Content-Type: text/plain; charset="iso-2022-jp"
|
||
Content-Transfer-Encoding: 8bit
|
||
|
||
On Wednesday 13 February 2002 21:07, Rod Taylor wrote:
|
||
> NAMEDATALEN's benchmarked are 32, 64, 128 and 512. Attached is the
|
||
> shell script I used to do it.
|
||
|
||
Attached is a modified version for Linux, if anyone is interested.
|
||
|
||
Will run it overnight out of quasi-scientific interest.
|
||
|
||
Nice to have an idea what kind of effect my very long NAMEDATALEN setting
|
||
(128) has.
|
||
|
||
|
||
Yours
|
||
|
||
Ian Barwick
|
||
--------------Boundary-00=_81THUZ3BONDS8SCE1A8O
|
||
Content-Type: application/x-shellscript; name="datalenbench.sh"
|
||
Content-Transfer-Encoding: base64
|
||
Content-Disposition: attachment; filename="datalenbench.sh"
|
||
|
||
IyEvYmluL3NoCgpQR1NSQz1+cG9zdGdyZXMvcGdiZW5jaC9wb3N0Z3Jlc3Fs
|
||
LTcuMgpQR0JBU0VQT1JUPTU0MDAKUEdCQVNFQklOPX5wb3N0Z3Jlcy9ob21l
|
||
L3Bvc3RncmVzL3BnYmVuY2gvcG9zdGdyZXM3MgoKTE9HPX5wb3N0Z3Jlcy9i
|
||
ZW5jaF9uYW1lZGF0YWxlbi5sb2cKCmZvciBuZXdEQVRBTEVOIGluIDMyIDY0
|
||
IDEyOCA1MTIgOyBkbwoKICBQR0JJTj0ke1BHQkFTRUJJTn1fJHtuZXdEQVRB
|
||
TEVOfQogIFBHUE9SVD1gZWNobyAiJHtQR0JBU0VQT1JUfSske25ld0RBVEFM
|
||
RU59IiB8IGJjYAoKICBzZWQgInMvTkFNRURBVEFMRU5bWzpzcGFjZTpdXVsw
|
||
LTldXHsxLFx9L05BTUVEQVRBTEVOICRuZXdEQVRBTEVOL2ciICR7UEdTUkN9
|
||
L3NyYy9pbmNsdWRlL3Bvc3RncmVzX2V4dC5oID4gJHtQR1NSQ30vc3JjL2lu
|
||
Y2x1ZGUvcG9zdGdyZXNfZXh0LmgudG1wCiAgbXYgJHtQR1NSQ30vc3JjL2lu
|
||
Y2x1ZGUvcG9zdGdyZXNfZXh0LmgudG1wICR7UEdTUkN9L3NyYy9pbmNsdWRl
|
||
L3Bvc3RncmVzX2V4dC5oCgogIGNkICR7UEdTUkN9CgogIC4vY29uZmlndXJl
|
||
IC0tcHJlZml4PSR7UEdCSU59IC0td2l0aC1wZ3BvcnQ9JHtQR1BPUlR9IHx8
|
||
IChlY2hvICJVTkFCTEUgVE8gQ09ORklHVVJFIjsgZXhpdCkKCiAgbWFrZSBj
|
||
bGVhbgogIG1ha2UgY2xlYW4gaW5zdGFsbAoKICBjZCAke1BHU1JDfS9jb250
|
||
cmliL3BnYmVuY2gKCiAgZ21ha2UgaW5zdGFsbAoKCiAgJHtQR0JJTn0vYmlu
|
||
L2luaXRkYiAtRCAke1BHQklOfS9kYXRhICB8fCAoZWNobyAiVU5BQkxFIFRP
|
||
IElOSVRJQUxJWkUiOyBleGl0IDEpCgogICR7UEdCSU59L2Jpbi9wZ19jdGwg
|
||
LUQgJHtQR0JJTn0vZGF0YSBzdGFydCAgfHwgKGVjaG8gIlVOQUJMRSBUTyBT
|
||
VEFSVCI7IGV4aXQgMSkKCiAgc2xlZXAgNQoKICBlY2hvICJOQU1FREFUQUxF
|
||
TjogJHtuZXdEQVRBTEVOfSIgPj4gJHtMT0d9CgogICMgcG9pbnQgdG8gR05V
|
||
IHRpbWUgKHNob3VsZCB3b3JrIG9uIHJlY2VudCBTdVNFIC8gUmVkSGF0KTsg
|
||
WU1NVgogIFRJTUU9L3Vzci9iaW4vdGltZQogIFRJTUVfRk9STUFUPSIlZSBy
|
||
ZWFsICVVIHVzZXIgJVMgc3lzIgoKICAkVElNRSAtYSAtbyAke0xPR30gLWYg
|
||
IiRUSU1FX0ZPUk1BVCIgJHtQR0JJTn0vYmluL3BnYmVuY2ggLWkgLXMgNSAt
|
||
ZCB0ZW1wbGF0ZTEgLXAgJHtQR1BPUlR9CgogICRUSU1FIC1hIC1vICR7TE9H
|
||
fSAtZiAiJFRJTUVfRk9STUFUIiAke1BHQklOfS9iaW4vcGdiZW5jaCAtdCAz
|
||
MDAwIC1zIDUgLWQgdGVtcGxhdGUxIC1wICR7UEdQT1JUfSAKICBlY2hvICA+
|
||
PiAke0xPR30KICBlY2hvICA+PiAke0xPR30KCiAgJHtQR0JJTn0vYmluL3Bn
|
||
X2N0bCAtRCAke1BHQklOfS9kYXRhIHN0b3AKICBybSAtcmYgJHtQR0JJTn0K
|
||
ZG9uZQoK
|
||
|
||
--------------Boundary-00=_81THUZ3BONDS8SCE1A8O
|
||
Content-Type: text/plain
|
||
Content-Disposition: inline
|
||
Content-Transfer-Encoding: binary
|
||
MIME-Version: 1.0
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
--------------Boundary-00=_81THUZ3BONDS8SCE1A8O--
|
||
|
||
From pgsql-hackers-owner+M18811=candle.pha.pa.us=pgman@postgresql.org Wed Feb 13 19:13:40 2002
|
||
Return-path: <pgsql-hackers-owner+M18811=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1E0DdP24221
|
||
for <pgman@candle.pha.pa.us>; Wed, 13 Feb 2002 19:13:39 -0500 (EST)
|
||
Received: (qmail 40165 invoked by alias); 14 Feb 2002 00:13:34 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 14 Feb 2002 00:13:34 -0000
|
||
Received: from student.gvsu.edu ([148.61.7.124])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g1E0ABE39822
|
||
for <pgsql-hackers@postgresql.org>; Wed, 13 Feb 2002 19:10:11 -0500 (EST)
|
||
(envelope-from peter_e@gmx.net)
|
||
Received: from [148.61.250.151] [148.61.250.151] by student.gvsu.edu
|
||
with Novonyx SMTP Server $Revision: 1.1 $; Wed, 13 Feb 2002 19:10:16 -0500 (EDT)
|
||
Date: Wed, 13 Feb 2002 19:12:57 -0500 (EST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
X-Sender: <peter@peter.localdomain>
|
||
To: Rod Taylor <rbt@zort.ca>
|
||
cc: Hackers List <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] NAMEDATALEN Changes
|
||
In-Reply-To: <003901c1b4ca$1d762500$8001a8c0@jester>
|
||
Message-ID: <Pine.LNX.4.30.0202131912010.683-100000@peter.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Rod Taylor writes:
|
||
|
||
> NAMEDATALEN's benchmarked are 32, 64, 128 and 512. Attached is the
|
||
> shell script I used to do it.
|
||
|
||
That's around a 15% performance loss for increasing it to 64 or 128.
|
||
Seems pretty scary actually.
|
||
|
||
--
|
||
Peter Eisentraut peter_e@gmx.net
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18815=candle.pha.pa.us=pgman@postgresql.org Wed Feb 13 20:02:31 2002
|
||
Return-path: <pgsql-hackers-owner+M18815=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1E12TP29895
|
||
for <pgman@candle.pha.pa.us>; Wed, 13 Feb 2002 20:02:29 -0500 (EST)
|
||
Received: (qmail 49786 invoked by alias); 14 Feb 2002 01:02:26 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 14 Feb 2002 01:02:26 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g1E10oE49562
|
||
for <pgsql-hackers@postgresql.org>; Wed, 13 Feb 2002 20:00:50 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g1E107f04416;
|
||
Wed, 13 Feb 2002 20:00:07 -0500 (EST)
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
cc: Rod Taylor <rbt@zort.ca>, Hackers List <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] NAMEDATALEN Changes
|
||
In-Reply-To: <Pine.LNX.4.30.0202131912010.683-100000@peter.localdomain>
|
||
References: <Pine.LNX.4.30.0202131912010.683-100000@peter.localdomain>
|
||
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
||
message dated "Wed, 13 Feb 2002 19:12:57 -0500"
|
||
Date: Wed, 13 Feb 2002 20:00:06 -0500
|
||
Message-ID: <4413.1013648406@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> That's around a 15% performance loss for increasing it to 64 or 128.
|
||
> Seems pretty scary actually.
|
||
|
||
Some of that could be bought back by fixing hashname() to not iterate
|
||
past the first \0 when calculating the hash of a NAME datum; and then
|
||
cc_hashname could go away. Not sure how much this would buy though.
|
||
|
||
Looking closely at Rod's script, I realize that the user+sys times it is
|
||
reporting are not the backend's but the pgbench client's. So it's
|
||
impossible to tell from this how much of the extra cost is extra I/O and
|
||
how much is CPU. I'm actually quite surprised that the client side
|
||
shows any CPU-time difference at all; I wouldn't think it ever sees any
|
||
null-padded NAME values.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
From pgsql-hackers-owner+M18817=candle.pha.pa.us=pgman@postgresql.org Thu Feb 14 01:22:04 2002
|
||
Return-path: <pgsql-hackers-owner+M18817=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1E6M3P26219
|
||
for <pgman@candle.pha.pa.us>; Thu, 14 Feb 2002 01:22:03 -0500 (EST)
|
||
Received: (qmail 83168 invoked by alias); 14 Feb 2002 06:22:05 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 14 Feb 2002 06:22:05 -0000
|
||
Received: from klamath.dyndns.org (CPE002078144ae0.cpe.net.cable.rogers.com [24.102.202.35])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g1E5xfE81904
|
||
for <pgsql-hackers@postgresql.org>; Thu, 14 Feb 2002 00:59:41 -0500 (EST)
|
||
(envelope-from nconway@klamath.dyndns.org)
|
||
Received: from localhost.localdomain (jiro [192.168.40.7])
|
||
by klamath.dyndns.org (Postfix) with ESMTP id 11D2E7007
|
||
for <pgsql-hackers@postgresql.org>; Thu, 14 Feb 2002 00:59:41 -0500 (EST)
|
||
Subject: Re: [HACKERS] NAMEDATALEN Changes
|
||
From: Neil Conway <nconway@klamath.dyndns.org>
|
||
To: pgsql-hackers@postgresql.org
|
||
In-Reply-To: <4413.1013648406@sss.pgh.pa.us>
|
||
References: <Pine.LNX.4.30.0202131912010.683-100000@peter.localdomain>
|
||
<4413.1013648406@sss.pgh.pa.us>
|
||
Content-Type: multipart/mixed; boundary="=-0nvLRoTY5hWeegGhITre"
|
||
X-Mailer: Evolution/1.0.2
|
||
Date: 14 Feb 2002 00:59:40 -0500
|
||
Message-ID: <1013666380.5380.19.camel@jiro>
|
||
MIME-Version: 1.0
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: ORr
|
||
|
||
--=-0nvLRoTY5hWeegGhITre
|
||
Content-Type: text/plain
|
||
Content-Transfer-Encoding: 7bit
|
||
|
||
On Wed, 2002-02-13 at 20:00, Tom Lane wrote:
|
||
> Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> > That's around a 15% performance loss for increasing it to 64 or 128.
|
||
> > Seems pretty scary actually.
|
||
>
|
||
> Some of that could be bought back by fixing hashname() to not iterate
|
||
> past the first \0 when calculating the hash of a NAME datum; and then
|
||
> cc_hashname could go away. Not sure how much this would buy though.
|
||
|
||
I've attached a pretty trivial patch that implements this. Instead of
|
||
automatically hashing NAMEDATALEN bytes, hashname() uses only strlen()
|
||
bytes: this should improve both the common case (small identifers, 5-10
|
||
characters long), as well as reduce the penalty when NAMEDATALEN is
|
||
increased. The patch passes the regression tests, FWIW. I didn't remove
|
||
cc_hashname() -- I'll tackle that tomorrow unless anyone objects...
|
||
|
||
I also did some pretty simple benchmarks; however, I'd appreciate it
|
||
anyone could confirm these results.
|
||
|
||
pg_bench: scale factor 1, 1 client, 10000 transactions.
|
||
|
||
hardware: p3-850, 384 MB RAM, slow laptop IDE disk
|
||
|
||
Run 1: Patch applied, NAMEDATALEN = 32
|
||
|
||
number of transactions actually processed: 10000/10000
|
||
tps = 19.940020(including connections establishing)
|
||
tps = 19.940774(excluding connections establishing)
|
||
|
||
Run 2: Patch applied, NAMEDATALEN = 128
|
||
|
||
number of transactions actually processed: 10000/10000
|
||
tps = 20.849385(including connections establishing)
|
||
tps = 20.850010(excluding connections establishing)
|
||
|
||
Run 3: Vanilla CVS, NAMEDATALEN = 32
|
||
(This is to check that the patch doesn't cause performance regressions
|
||
for the "common case")
|
||
|
||
number of transactions actually processed: 10000/10000
|
||
tps = 18.295418(including connections establishing)
|
||
tps = 18.296191(excluding connections establishing)
|
||
|
||
The performance improvement @ NAMEDATALEN = 128 seems strange. As I
|
||
said, these benchmarks may not be particularly accurate, so I'd suggest
|
||
waiting for others to contribute results before drawing any conclusions.
|
||
|
||
Oh, and this is my first "real" Pg patch, so my apologies if I've
|
||
screwed something up. ;-)
|
||
|
||
Cheers,
|
||
|
||
Neil
|
||
|
||
--
|
||
Neil Conway <neilconway@rogers.com>
|
||
PGP Key ID: DB3C29FC
|
||
|
||
--=-0nvLRoTY5hWeegGhITre
|
||
Content-Disposition: attachment; filename=hash_len.patch
|
||
Content-Transfer-Encoding: quoted-printable
|
||
Content-Type: text/x-patch; charset=ISO-8859-1
|
||
|
||
*** ./src/backend/access/hash/hashfunc.c.orig Wed Feb 13 21:09:37 2002
|
||
--- ./src/backend/access/hash/hashfunc.c Thu Feb 14 00:39:42 2002
|
||
***************
|
||
*** 95,101 ****
|
||
{
|
||
char *key =3D NameStr(*PG_GETARG_NAME(0));
|
||
=20=20
|
||
! return hash_any((char *) key, NAMEDATALEN);
|
||
}
|
||
=20=20
|
||
/*
|
||
--- 95,101 ----
|
||
{
|
||
char *key =3D NameStr(*PG_GETARG_NAME(0));
|
||
=20=20
|
||
! return hash_any(key, strlen(key));
|
||
}
|
||
=20=20
|
||
/*
|
||
***************
|
||
*** 125,131 ****
|
||
*
|
||
* (Comment from the original db3 hashing code: )
|
||
*
|
||
! * "This is INCREDIBLY ugly, but fast. We break the string up into 8 byte
|
||
* units. On the first time through the loop we get the 'leftover bytes'
|
||
* (strlen % 8). On every later iteration, we perform 8 HASHC's so we ha=
|
||
ndle
|
||
* all 8 bytes. Essentially, this saves us 7 cmp & branch instructions. =
|
||
If
|
||
--- 125,131 ----
|
||
*
|
||
* (Comment from the original db3 hashing code: )
|
||
*
|
||
! * This is INCREDIBLY ugly, but fast. We break the string up into 8 byte
|
||
* units. On the first time through the loop we get the 'leftover bytes'
|
||
* (strlen % 8). On every later iteration, we perform 8 HASHC's so we ha=
|
||
ndle
|
||
* all 8 bytes. Essentially, this saves us 7 cmp & branch instructions. =
|
||
If
|
||
***************
|
||
*** 134,140 ****
|
||
* "OZ's original sdbm hash"
|
||
*/
|
||
Datum
|
||
! hash_any(char *keydata, int keylen)
|
||
{
|
||
uint32 n;
|
||
int loop;
|
||
--- 134,140 ----
|
||
* "OZ's original sdbm hash"
|
||
*/
|
||
Datum
|
||
! hash_any(const char *keydata, int keylen)
|
||
{
|
||
uint32 n;
|
||
int loop;
|
||
*** ./src/include/access/hash.h.orig Wed Feb 13 22:43:06 2002
|
||
--- ./src/include/access/hash.h Thu Feb 14 00:38:35 2002
|
||
***************
|
||
*** 265,271 ****
|
||
extern Datum hashint2vector(PG_FUNCTION_ARGS);
|
||
extern Datum hashname(PG_FUNCTION_ARGS);
|
||
extern Datum hashvarlena(PG_FUNCTION_ARGS);
|
||
! extern Datum hash_any(char *keydata, int keylen);
|
||
=20=20
|
||
=20=20
|
||
/* private routines */
|
||
--- 265,271 ----
|
||
extern Datum hashint2vector(PG_FUNCTION_ARGS);
|
||
extern Datum hashname(PG_FUNCTION_ARGS);
|
||
extern Datum hashvarlena(PG_FUNCTION_ARGS);
|
||
! extern Datum hash_any(const char *keydata, int keylen);
|
||
=20=20
|
||
=20=20
|
||
/* private routines */
|
||
|
||
--=-0nvLRoTY5hWeegGhITre
|
||
Content-Type: text/plain
|
||
Content-Disposition: inline
|
||
Content-Transfer-Encoding: binary
|
||
MIME-Version: 1.0
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
|
||
|
||
--=-0nvLRoTY5hWeegGhITre--
|
||
|
||
|
||
From pgsql-hackers-owner+M18819=candle.pha.pa.us=pgman@postgresql.org Thu Feb 14 09:03:43 2002
|
||
Return-path: <pgsql-hackers-owner+M18819=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1EE3gP17661
|
||
for <pgman@candle.pha.pa.us>; Thu, 14 Feb 2002 09:03:42 -0500 (EST)
|
||
Received: (qmail 68050 invoked by alias); 14 Feb 2002 14:03:37 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 14 Feb 2002 14:03:37 -0000
|
||
Received: from CopelandConsulting.Net (dsl-24293-ld.customer.centurytel.net [209.142.135.135])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g1EE1FE67720
|
||
for <pgsql-hackers@postgresql.org>; Thu, 14 Feb 2002 09:01:15 -0500 (EST)
|
||
(envelope-from greg@copelandconsulting.net)
|
||
Received: from there (mouse.copelandconsulting.net [192.168.1.2])
|
||
by CopelandConsulting.Net (8.10.1/8.10.1) with SMTP id g1EE1Dk24399;
|
||
Thu, 14 Feb 2002 08:01:14 -0600 (CST)
|
||
Message-ID: <CCC.200202141401.g1EE1Dk24399@CopelandConsulting.Net>
|
||
X-Trade-Id: <CCC.Thu, 14 Feb 2002 08:01:14 -0600 (CST).Thu, 14 Feb 2002 08:01:14 -0600 (CST).200202141401.g1EE1Dk24399.g1EE1Dk24399@CopelandConsulting.Net.
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
From: Greg Copeland <greg@CopelandConsulting.Net>
|
||
Organization: Copeland Computer Consulting
|
||
To: Neil Conway <nconway@klamath.dyndns.org>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] NAMEDATALEN Changes
|
||
Date: Thu, 14 Feb 2002 08:00:58 -0600
|
||
X-Mailer: KMail [version 1.3.1]
|
||
References: <Pine.LNX.4.30.0202131912010.683-100000@peter.localdomain> <4413.1013648406@sss.pgh.pa.us> <1013666380.5380.19.camel@jiro>
|
||
In-Reply-To: <1013666380.5380.19.camel@jiro>
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 8bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
-----BEGIN PGP SIGNED MESSAGE-----
|
||
Hash: SHA1
|
||
|
||
On Wednesday 13 February 2002 23:59, Neil Conway wrote:
|
||
> On Wed, 2002-02-13 at 20:00, Tom Lane wrote:
|
||
|
||
[perf hit comment removed]
|
||
|
||
>
|
||
> I've attached a pretty trivial patch that implements this. Instead of
|
||
> automatically hashing NAMEDATALEN bytes, hashname() uses only strlen()
|
||
> bytes: this should improve both the common case (small identifers, 5-10
|
||
> characters long), as well as reduce the penalty when NAMEDATALEN is
|
||
> increased. The patch passes the regression tests, FWIW. I didn't remove
|
||
> cc_hashname() -- I'll tackle that tomorrow unless anyone objects...
|
||
>
|
||
> I also did some pretty simple benchmarks; however, I'd appreciate it
|
||
> anyone could confirm these results.
|
||
>
|
||
|
||
Please bare with me on this as this is my first posting having any real
|
||
content. <20>Please don't hang me out if I've overlooked anything and I'm
|
||
pointing out that I'm making a rather large assumption. Please correct as
|
||
needed.
|
||
|
||
The primary assumption is that the actual key lengths can be less than
|
||
NAMEDATALEN. That is, if the string, "shortkey" is a valid input key (??)
|
||
which provides a key length of 8-bytes as input to the hash_any() function
|
||
even though NAMEDATALEN may be something like 128 or larger. If this
|
||
assumption is correct, then wouldn't increasing the default input key size
|
||
(NAMEDATALEN) beyond the maximum actual key length be a bug? That is to say,
|
||
if we have a key with only 8-bytes of data and we iterrate over 128-bytes,
|
||
wouldn't the resulting hash be arbitrary and invalid as it would be hashing
|
||
memory which is not reflective of the key being hashed?
|
||
|
||
If my assumptions are correct, then it sounds like using the strlen()
|
||
implementation (assuming input keys are valid C-strings) is really the proper
|
||
implementation short of using an adjusted min(NAMEDATALEN,strlen()) type
|
||
approach.
|
||
|
||
[snip - var NAMEDATALEN benchmark results]
|
||
|
||
|
||
Greg
|
||
-----BEGIN PGP SIGNATURE-----
|
||
Version: GnuPG v1.0.6 (GNU/Linux)
|
||
Comment: For info see http://www.gnupg.org
|
||
|
||
iD8DBQE8a8Mg4lr1bpbcL6kRAlaxAJ47CO+ExL/ZMo/i6LDoetXrul9qqQCfQli3
|
||
AvqN6RJjSuAH/p/mpZ8J4JY=
|
||
=wnVM
|
||
-----END PGP SIGNATURE-----
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 5: Have you checked our extensive FAQ?
|
||
|
||
http://www.postgresql.org/users-lounge/docs/faq.html
|
||
|
||
From pgsql-hackers-owner+M18820=candle.pha.pa.us=pgman@postgresql.org Thu Feb 14 10:14:25 2002
|
||
Return-path: <pgsql-hackers-owner+M18820=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1EFEOP25217
|
||
for <pgman@candle.pha.pa.us>; Thu, 14 Feb 2002 10:14:24 -0500 (EST)
|
||
Received: (qmail 80096 invoked by alias); 14 Feb 2002 15:14:19 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 14 Feb 2002 15:14:19 -0000
|
||
Received: from sss.pgh.pa.us ([192.204.191.242])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g1EEvpE77298
|
||
for <pgsql-hackers@postgresql.org>; Thu, 14 Feb 2002 09:57:51 -0500 (EST)
|
||
(envelope-from tgl@sss.pgh.pa.us)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g1EEvof08568;
|
||
Thu, 14 Feb 2002 09:57:50 -0500 (EST)
|
||
To: Greg Copeland <greg@CopelandConsulting.Net>
|
||
cc: Neil Conway <nconway@klamath.dyndns.org>, pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] NAMEDATALEN Changes
|
||
In-Reply-To: <CCC.200202141401.g1EE1Dk24399@CopelandConsulting.Net>
|
||
References: <Pine.LNX.4.30.0202131912010.683-100000@peter.localdomain> <4413.1013648406@sss.pgh.pa.us> <1013666380.5380.19.camel@jiro> <CCC.200202141401.g1EE1Dk24399@CopelandConsulting.Net>
|
||
Comments: In-reply-to Greg Copeland <greg@CopelandConsulting.Net>
|
||
message dated "Thu, 14 Feb 2002 08:00:58 -0600"
|
||
Date: Thu, 14 Feb 2002 09:57:50 -0500
|
||
Message-ID: <8565.1013698670@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
Greg Copeland <greg@CopelandConsulting.Net> writes:
|
||
> if we have a key with only 8-bytes of data and we iterrate over 128-bytes,
|
||
> wouldn't the resulting hash be arbitrary and invalid as it would be hashing
|
||
> memory which is not reflective of the key being hashed?
|
||
|
||
As long as we do it *consistently*, we can do it either way. Using the
|
||
trailing nulls in the hash does alter the computed hash value --- but
|
||
we're only ever gonna compare the hash value against other hash values
|
||
computed on other NAMEs by this same routine.
|
||
|
||
This all assumes that the inputs are valid NAMEs, viz strlen <
|
||
NAMEDATALEN and no funny business beyond the first \0. In practice,
|
||
however, if a bogus NAME were handed to us we would just as soon ignore
|
||
any characters beyond the first \0, because the ordering comparison
|
||
operators for NAME all do so (they're all based on strncmp), as do the
|
||
I/O routines etc. So this change actually makes the system more
|
||
self-consistent not less so.
|
||
|
||
regards, tom lane
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 6: Have you searched our list archives?
|
||
|
||
http://archives.postgresql.org
|
||
|
||
From pgsql-hackers-owner+M18827=candle.pha.pa.us=pgman@postgresql.org Thu Feb 14 13:53:52 2002
|
||
Return-path: <pgsql-hackers-owner+M18827=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1EIrpP17729
|
||
for <pgman@candle.pha.pa.us>; Thu, 14 Feb 2002 13:53:51 -0500 (EST)
|
||
Received: (qmail 47648 invoked by alias); 14 Feb 2002 18:53:50 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 14 Feb 2002 18:53:50 -0000
|
||
Received: from klamath.dyndns.org (CPE002078144ae0.cpe.net.cable.rogers.com [24.102.202.35])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g1EIbiE46318
|
||
for <pgsql-hackers@postgresql.org>; Thu, 14 Feb 2002 13:37:44 -0500 (EST)
|
||
(envelope-from nconway@klamath.dyndns.org)
|
||
Received: by klamath.dyndns.org (Postfix, from userid 1000)
|
||
id 032E8700C; Thu, 14 Feb 2002 13:37:44 -0500 (EST)
|
||
Date: Thu, 14 Feb 2002 13:37:43 -0500
|
||
To: pgsql-hackers@postgresql.org
|
||
Subject: Re: [HACKERS] NAMEDATALEN Changes
|
||
Message-ID: <20020214183743.GA10423@klamath.dyndns.org>
|
||
Mail-Followup-To: pgsql-hackers@postgresql.org
|
||
References: <Pine.LNX.4.30.0202131912010.683-100000@peter.localdomain> <4413.1013648406@sss.pgh.pa.us> <1013666380.5380.19.camel@jiro>
|
||
MIME-Version: 1.0
|
||
Content-Type: multipart/mixed; boundary="huq684BweRXVnRxX"
|
||
Content-Disposition: inline
|
||
In-Reply-To: <1013666380.5380.19.camel@jiro>
|
||
User-Agent: Mutt/1.3.27i
|
||
From: nconway@klamath.dyndns.org (Neil Conway)
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
--huq684BweRXVnRxX
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Disposition: inline
|
||
|
||
On Thu, Feb 14, 2002 at 12:59:40AM -0500, Neil Conway wrote:
|
||
> I've attached a pretty trivial patch that implements this. Instead of
|
||
> automatically hashing NAMEDATALEN bytes, hashname() uses only strlen()
|
||
> bytes: this should improve both the common case (small identifers, 5-10
|
||
> characters long), as well as reduce the penalty when NAMEDATALEN is
|
||
> increased. The patch passes the regression tests, FWIW. I didn't remove
|
||
> cc_hashname() -- I'll tackle that tomorrow unless anyone objects...
|
||
|
||
Okay, I've attached a new version that removes cc_hashname(). As with
|
||
the previous patch, this passes the regression tests. Feedback is welcome.
|
||
|
||
Cheers,
|
||
|
||
Neil
|
||
|
||
|
||
--huq684BweRXVnRxX
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Disposition: attachment; filename="hash_len.patch"
|
||
|
||
*** ./src/backend/access/hash/hashfunc.c.orig Wed Feb 13 21:09:37 2002
|
||
--- ./src/backend/access/hash/hashfunc.c Thu Feb 14 00:39:42 2002
|
||
***************
|
||
*** 95,101 ****
|
||
{
|
||
char *key = NameStr(*PG_GETARG_NAME(0));
|
||
|
||
! return hash_any((char *) key, NAMEDATALEN);
|
||
}
|
||
|
||
/*
|
||
--- 95,101 ----
|
||
{
|
||
char *key = NameStr(*PG_GETARG_NAME(0));
|
||
|
||
! return hash_any(key, strlen(key));
|
||
}
|
||
|
||
/*
|
||
***************
|
||
*** 125,131 ****
|
||
*
|
||
* (Comment from the original db3 hashing code: )
|
||
*
|
||
! * "This is INCREDIBLY ugly, but fast. We break the string up into 8 byte
|
||
* units. On the first time through the loop we get the 'leftover bytes'
|
||
* (strlen % 8). On every later iteration, we perform 8 HASHC's so we handle
|
||
* all 8 bytes. Essentially, this saves us 7 cmp & branch instructions. If
|
||
--- 125,131 ----
|
||
*
|
||
* (Comment from the original db3 hashing code: )
|
||
*
|
||
! * This is INCREDIBLY ugly, but fast. We break the string up into 8 byte
|
||
* units. On the first time through the loop we get the 'leftover bytes'
|
||
* (strlen % 8). On every later iteration, we perform 8 HASHC's so we handle
|
||
* all 8 bytes. Essentially, this saves us 7 cmp & branch instructions. If
|
||
***************
|
||
*** 134,140 ****
|
||
* "OZ's original sdbm hash"
|
||
*/
|
||
Datum
|
||
! hash_any(char *keydata, int keylen)
|
||
{
|
||
uint32 n;
|
||
int loop;
|
||
--- 134,140 ----
|
||
* "OZ's original sdbm hash"
|
||
*/
|
||
Datum
|
||
! hash_any(const char *keydata, int keylen)
|
||
{
|
||
uint32 n;
|
||
int loop;
|
||
*** ./src/backend/utils/cache/catcache.c.orig Thu Feb 14 12:51:00 2002
|
||
--- ./src/backend/utils/cache/catcache.c Thu Feb 14 12:53:05 2002
|
||
***************
|
||
*** 93,99 ****
|
||
static Index CatalogCacheComputeTupleHashIndex(CatCache *cache,
|
||
HeapTuple tuple);
|
||
static void CatalogCacheInitializeCache(CatCache *cache);
|
||
- static Datum cc_hashname(PG_FUNCTION_ARGS);
|
||
|
||
|
||
/*
|
||
--- 93,98 ----
|
||
***************
|
||
*** 109,115 ****
|
||
case CHAROID:
|
||
return hashchar;
|
||
case NAMEOID:
|
||
! return cc_hashname;
|
||
case INT2OID:
|
||
return hashint2;
|
||
case INT2VECTOROID:
|
||
--- 108,114 ----
|
||
case CHAROID:
|
||
return hashchar;
|
||
case NAMEOID:
|
||
! return hashname;
|
||
case INT2OID:
|
||
return hashint2;
|
||
case INT2VECTOROID:
|
||
***************
|
||
*** 129,151 ****
|
||
return (PGFunction) NULL;
|
||
}
|
||
}
|
||
-
|
||
- static Datum
|
||
- cc_hashname(PG_FUNCTION_ARGS)
|
||
- {
|
||
- /*
|
||
- * We need our own variant of hashname because we want to accept
|
||
- * null-terminated C strings as search values for name fields. So, we
|
||
- * have to make sure the data is correctly padded before we compute
|
||
- * the hash value.
|
||
- */
|
||
- NameData my_n;
|
||
-
|
||
- namestrcpy(&my_n, NameStr(*PG_GETARG_NAME(0)));
|
||
-
|
||
- return DirectFunctionCall1(hashname, NameGetDatum(&my_n));
|
||
- }
|
||
-
|
||
|
||
/*
|
||
* Standard routine for creating cache context if it doesn't exist yet
|
||
--- 128,133 ----
|
||
*** ./src/include/access/hash.h.orig Wed Feb 13 22:43:06 2002
|
||
--- ./src/include/access/hash.h Thu Feb 14 00:38:35 2002
|
||
***************
|
||
*** 265,271 ****
|
||
extern Datum hashint2vector(PG_FUNCTION_ARGS);
|
||
extern Datum hashname(PG_FUNCTION_ARGS);
|
||
extern Datum hashvarlena(PG_FUNCTION_ARGS);
|
||
! extern Datum hash_any(char *keydata, int keylen);
|
||
|
||
|
||
/* private routines */
|
||
--- 265,271 ----
|
||
extern Datum hashint2vector(PG_FUNCTION_ARGS);
|
||
extern Datum hashname(PG_FUNCTION_ARGS);
|
||
extern Datum hashvarlena(PG_FUNCTION_ARGS);
|
||
! extern Datum hash_any(const char *keydata, int keylen);
|
||
|
||
|
||
/* private routines */
|
||
|
||
--huq684BweRXVnRxX
|
||
Content-Type: text/plain
|
||
Content-Disposition: inline
|
||
Content-Transfer-Encoding: binary
|
||
MIME-Version: 1.0
|
||
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|
||
--huq684BweRXVnRxX--
|
||
|
||
From pgsql-hackers-owner+M18833=candle.pha.pa.us=pgman@postgresql.org Thu Feb 14 16:22:34 2002
|
||
Return-path: <pgsql-hackers-owner+M18833=candle.pha.pa.us=pgman@postgresql.org>
|
||
Received: from server1.pgsql.org (www.postgresql.org [64.49.215.9])
|
||
by candle.pha.pa.us (8.11.6/8.10.1) with SMTP id g1ELMXP07956
|
||
for <pgman@candle.pha.pa.us>; Thu, 14 Feb 2002 16:22:34 -0500 (EST)
|
||
Received: (qmail 80517 invoked by alias); 14 Feb 2002 21:22:29 -0000
|
||
Received: from unknown (HELO postgresql.org) (64.49.215.8)
|
||
by www.postgresql.org with SMTP; 14 Feb 2002 21:22:29 -0000
|
||
Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65])
|
||
by postgresql.org (8.11.3/8.11.4) with ESMTP id g1EL2mE77720
|
||
for <pgsql-hackers@postgresql.org>; Thu, 14 Feb 2002 16:02:48 -0500 (EST)
|
||
(envelope-from barwick@gmx.net)
|
||
Received: from there (pD9EB17D4.dip.t-dialin.net [217.235.23.212])
|
||
by post.webmailer.de (8.9.3/8.8.7) with SMTP id WAA07320
|
||
for <pgsql-hackers@postgresql.org>; Thu, 14 Feb 2002 22:02:49 +0100 (MET)
|
||
Message-ID: <200202142102.WAA07320@post.webmailer.de>
|
||
Content-Type: text/plain;
|
||
charset="iso-2022-jp"
|
||
From: Ian Barwick <barwick@gmx.net>
|
||
To: "Hackers List" <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] NAMEDATALEN Changes
|
||
Date: Thu, 14 Feb 2002 22:02:34 +0100
|
||
X-Mailer: KMail [version 1.3.1]
|
||
References: <003901c1b4ca$1d762500$8001a8c0@jester> <200202132227.XAA22201@post.webmailer.de>
|
||
In-Reply-To: <200202132227.XAA22201@post.webmailer.de>
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 8bit
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@postgresql.org
|
||
Status: OR
|
||
|
||
On Wednesday 13 February 2002 23:27, Ian Barwick wrote:
|
||
> On Wednesday 13 February 2002 21:07, Rod Taylor wrote:
|
||
> > NAMEDATALEN's benchmarked are 32, 64, 128 and 512. Attached is the
|
||
> > shell script I used to do it.
|
||
>
|
||
> Attached is a modified version for Linux, if anyone is interested.
|
||
>
|
||
> Will run it overnight out of quasi-scientific interest.
|
||
>
|
||
> Nice to have an idea what kind of effect my very long NAMEDATALEN setting
|
||
> (128) has.
|
||
|
||
Below the probably quite uninformative results, run under Linux with 2.2.16
|
||
on an AMD K2 350Mhz with 256MB RAM, EIDE HDs and other run of the mill
|
||
hardware.
|
||
|
||
I suspect some of the normal system jobs which usually run during the night
|
||
caused the wildly varying results. Whatever else, for my purposes at least
|
||
any performance issues with differening NAMEDATALENgths are nothing much
|
||
to worry about.
|
||
|
||
|
||
NAMEDATALEN: 32
|
||
220.73 real 3.39 user 0.10 sys
|
||
110.03 real 2.77 user 4.42 sys
|
||
|
||
|
||
NAMEDATALEN: 64
|
||
205.31 real 3.55 user 0.08 sys
|
||
109.76 real 2.53 user 4.18 sys
|
||
|
||
|
||
NAMEDATALEN: 128
|
||
224.65 real 3.35 user 0.10 sys
|
||
121.30 real 2.60 user 3.89 sys
|
||
|
||
|
||
NAMEDATALEN: 256
|
||
209.48 real 3.62 user 0.11 sys
|
||
118.90 real 3.00 user 3.88 sys
|
||
|
||
|
||
NAMEDATALEN: 512
|
||
204.65 real 3.36 user 0.14 sys
|
||
115.12 real 2.54 user 3.88 sys
|
||
|
||
|
||
Ian Barwick
|
||
|
||
---------------------------(end of broadcast)---------------------------
|
||
TIP 3: if posting/reading through Usenet, please send an appropriate
|
||
subscribe-nomail command to majordomo@postgresql.org so that your
|
||
message can get through to the mailing list cleanly
|
||
|