X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 350F7DAE89 for ; Wed, 23 Nov 2005 22:29:56 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 19797-10 for ; Thu, 24 Nov 2005 02:29:59 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.mi8.com (d01gw04.mi8.com [63.240.6.44]) by svr1.postgresql.org (Postfix) with ESMTP id 48D7DDA86D for ; Wed, 23 Nov 2005 22:29:52 -0400 (AST) Received: from 172.16.1.112 by mail.mi8.com with ESMTP (- Welcome to Mi8 Corporation www.Mi8.com (D4)); Wed, 23 Nov 2005 21:29:51 -0500 X-Server-Uuid: C8FB4D43-1108-484A-A898-3CBCC7906230 Received: from MI8NYCMAIL06.Mi8.com ([172.16.1.175]) by D01SMTP02.Mi8.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 21:29:50 -0500 Received: from 208.54.15.129 ([208.54.15.129]) by MI8NYCMAIL06.Mi8.com ( [172.16.1.219]) via Exchange Front-End Server mi8owa.mi8.com ( [172.16.1.106]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Nov 2005 21:29:50 -0500 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 23 Nov 2005 18:29:49 -0800 Subject: Re: Hardware/OS recommendations for large databases ( From: "Luke Lonergan" To: "Mark Kirkwood" cc: pgsql-performance@postgresql.org, "eng@intranet.greenplum.com" Message-ID: Thread-Topic: [PERFORM] Hardware/OS recommendations for large databases ( Thread-Index: AcXvIxdwfLDwWrP8Q669kHxJ85F1twBe9mid In-Reply-To: <4382A840.3030401@paradise.net.nz> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2005 02:29:50.0935 (UTC) FILETIME=[F23A8E70:01C5F09E] X-WSS-ID: 6F9BFA152UO2837356-01-01 Content-Type: multipart/alternative; boundary=B_3215615389_18058204 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=2.387 required=5 tests=[AWL=-0.103, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=1.236, RCVD_NUMERIC_HELO=1.253] X-Spam-Score: 2.387 X-Spam-Level: ** X-Archive-Number: 200511/478 X-Sequence-Number: 15735 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3215615389_18058204 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Mark, This is an excellent idea =AD unfortunately I=B9m in Maui right now (Mahalo!) and I=B9m not getting to testing with this. My first try was with 8.0.3 and it=B9s an 8.1 function I presume. Not to be lazy =AD but any hint as to how to do the same thing for 8.0? - Luke On 11/21/05 9:10 PM, "Mark Kirkwood" wrote: > Luke Lonergan wrote: >=20 >> > So that leaves the question - why not more than 64% of the I/O scan ra= te? >> > And why is it a flat 64% as the I/O subsystem increases in speed from >> > 333-400MB/s? >> > >=20 > It might be interesting to see what effect reducing the cpu consumption > entailed by the count aggregation has - by (say) writing a little bit > of code to heap scan the desired relation (sample attached). >=20 > Cheers >=20 > Mark >=20 >=20 >=20 >=20 >=20 >=20 > /* > * fastcount.c > * > * Do a count that uses considerably less CPU time than an aggregate. > */ >=20 > #include "postgres.h" >=20 > #include "funcapi.h" > #include "access/heapam.h" > #include "catalog/namespace.h" > #include "utils/builtins.h" >=20 >=20 > extern Datum fastcount(PG_FUNCTION_ARGS); >=20 >=20 > PG_FUNCTION_INFO_V1(fastcount); > Datum > fastcount(PG_FUNCTION_ARGS) > { > text *relname =3D PG_GETARG_TEXT_P(0); > RangeVar *relrv; > Relation rel; > HeapScanDesc scan; > HeapTuple tuple; > int64 result =3D 0; >=20 > /* Use the name to get a suitable range variable and open the relation. = */ > relrv =3D makeRangeVarFromNameList(textToQualifiedNameList(relname)); > rel =3D heap_openrv(relrv, AccessShareLock); >=20 > /* Start a heap scan on the relation. */ > scan =3D heap_beginscan(rel, SnapshotNow, 0, NULL); > while ((tuple =3D heap_getnext(scan, ForwardScanDirection)) !=3D NULL) > { > result++; > } >=20 > /* End the scan and close up the relation. */ > heap_endscan(scan); > heap_close(rel, AccessShareLock); >=20 >=20 > PG_RETURN_INT64(result); > } --B_3215615389_18058204 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Re: [PERFORM] Hardware/OS recommendations for large databases (</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:14.0px'>Mark,= <BR> <BR> This is an excellent idea – unfortunately I’m in Maui right now= (Mahalo!) and I’m not getting to testing with this.  My first tr= y was with 8.0.3 and it’s an 8.1 function I presume.<BR> <BR> Not to be lazy – but any hint as to how to do the same thing for 8.0?= <BR> <BR> - Luke<BR> <BR> <BR> On 11/21/05 9:10 PM, "Mark Kirkwood" <markir@paradise.net.nz&g= t; wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL= E=3D'font-size:14.0px'>Luke Lonergan wrote:<BR> <BR> > So that leaves the question - why not more than 64% of the I/O scan ra= te?<BR> > And why is it a flat 64% as the I/O subsystem increases in speed from<= BR> > 333-400MB/s?<BR> ><BR> <BR> It might be interesting to see what effect reducing the cpu consumption<BR>   entailed by the count aggregation has - by (say) writing a litt= le bit<BR> of code to heap scan the desired relation (sample attached).<BR> <BR> Cheers<BR> <BR> Mark<BR> <BR> <BR> <BR> <BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA= CE=3D"Monaco, Courier New"><SPAN STYLE=3D'font-size:12.0px'>/*<BR>  * fastcount.c<BR>  *<BR>  * Do a count that uses considerably less CPU time than an aggregate.<= BR>  */<BR> <BR> #include "postgres.h"<BR> <BR> #include "funcapi.h"<BR> #include "access/heapam.h"<BR> #include "catalog/namespace.h"<BR> #include "utils/builtins.h"<BR> <BR> <BR> extern Datum fastcount(PG_FUNCTION_ARGS);<BR> <BR> <BR> PG_FUNCTION_INFO_V1(fastcount);<BR> Datum<BR> fastcount(PG_FUNCTION_ARGS)<BR> {<BR>  text    *relname =3D PG_GETARG_TEXT_P(0);<BR>  RangeVar   *relrv;<BR>  Relation rel;<BR>  HeapScanDesc scan;<BR>  HeapTuple tuple;<BR>  int64  result =3D 0;<BR> <BR>  /* Use the name to get a suitable range variable and open the relatio= n. */<BR>  relrv =3D makeRangeVarFromNameList(textToQualifiedNameList(relname));<B= R>  rel =3D heap_openrv(relrv, AccessShareLock);<BR> <BR>  /* Start a heap scan on the relation. */<BR>  scan =3D heap_beginscan(rel, SnapshotNow, 0, NULL);<BR>  while ((tuple =3D heap_getnext(scan, ForwardScanDirection)) !=3D NULL)<BR= >  {<BR>   result++;<BR>  }<BR> <BR>  /* End the scan and close up the relation. */<BR>  heap_endscan(scan);<BR>  heap_close(rel, AccessShareLock);<BR> <BR> <BR>  PG_RETURN_INT64(result);<BR> }<BR> </SPAN></FONT></FONT></BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courie= r New"><SPAN STYLE=3D'font-size:12.0px'><BR> </SPAN></FONT></FONT> </BODY> </HTML> --B_3215615389_18058204--