mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-28 19:27:19 +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
|
|||
|
|