+++ /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
-
OSDN Git Service
