--- /dev/null
+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. 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
+
projects / postgresql / commitdiff