X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 1369B5331C for ; Sat, 14 May 2005 10:00:51 -0300 (ADT) 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 73363-03 for ; Sat, 14 May 2005 13:00:50 +0000 (GMT) Received: from boutiquenumerique.com (boutiquenumerique.com [82.67.9.10]) by svr1.postgresql.org (Postfix) with ESMTP id 287B452968 for ; Sat, 14 May 2005 10:00:48 -0300 (ADT) Received: (qmail 28660 invoked from network); 14 May 2005 15:01:13 +0200 Received: from unknown (HELO localhost) (boutiquenumerique-lists@192.168.0.4) by boutiquenumerique.com with SMTP; 14 May 2005 15:01:13 +0200 To: "Alex Turner" Cc: pgsql-performance@postgresql.org Subject: Re: Partitioning / Clustering References: <5F94B6EB-3925-4CD3-A67F-4310890B438A@advfn.com> <200505111013.52067.josh@agliodbs.com> <1115798277.29223.233869472@webmail.messagingengine.com> <33c6269f050512070842df1af3@mail.gmail.com> Message-ID: Date: Sat, 14 May 2005 15:00:47 +0200 From: PFC Organization: =?iso-8859-15?Q?La_Boutique_Num=E9rique?= Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <200505111013.52067.josh@agliodbs.com> User-Agent: Opera M2(BETA2)/8.0 (Linux, build 987) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.002 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200505/279 X-Sequence-Number: 12443 > If you make the assertion that you are transferring equal or less > session data between your session server (lets say an RDBMS) and the > app server than you are between the app server and the client, an out > of band 100Mb network for session information is plenty of bandwidth. So if you count on a mean page size of 6-8 kbytes gzipped, that will prevent you from caching the N first results of the Big Slow Search Query in a native object in the user session state (say, a list of integers indicating which rows match), so you will have to redo the Big Slow Search Query everytime the user clicks on Next Page instead of grabbing a set of cached row id's and doing a fast SELECT WHERE id IN ... This is the worst case ... I'd gzip() the row id's and stuff them in the session, that's always better than blowing up the database with the Big Slow Search Query everytime someone does Next Page... > This also represents OLTP style traffic, which postgresql is pretty > good at. You should easily be able to get over 100Tps. 100 hits per > second is an awful lot of traffic, more than any website I've managed > will ever see. On the latest anandtech benchmarks, 100 hits per second on a blog/forum software is a big bi-opteron server running dotNET, at 99% load... it's a lot if you count only dynamic page hits.