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 0F5098B9CFB for ; Tue, 1 Feb 2005 09:14:26 +0000 (GMT) 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 37641-08 for ; Tue, 1 Feb 2005 09:14:15 +0000 (GMT) Received: from boutiquenumerique.com (boutiquenumerique.com [82.67.9.10]) by svr1.postgresql.org (Postfix) with ESMTP id 7D4588B9BF5 for ; Tue, 1 Feb 2005 09:14:15 +0000 (GMT) Received: (qmail 22824 invoked from network); 1 Feb 2005 10:14:35 +0100 Received: from unknown (HELO musicbox) (boutiquenumerique-lists@192.168.0.2) by boutiquenumerique.com with SMTP; 1 Feb 2005 10:14:35 +0100 To: alex@neteconomist.com, "Andrei Bintintan" Cc: pgsql-performance@postgresql.org Subject: Re: [SQL] OFFSET impact on Performance??? References: <019f01c4fee1$1b58d600$0b00a8c0@forge> <41EF9FD3.5020400@archonet.com> <020d01c4fef6$595bb9d0$0b00a8c0@forge> <41EFCC5B.5010302@archonet.com> <33c6269f05012008391490448b@mail.gmail.com> <87y8eh1hy9.fsf@stark.xeocode.com> <015a01c5038f$73a70720$0b00a8c0@forge> <33c6269f05012605473319ef40@mail.gmail.com> Message-ID: Date: Tue, 01 Feb 2005 10:16:47 +0100 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: <33c6269f05012605473319ef40@mail.gmail.com> User-Agent: Opera M2/7.54 (Linux, build 751) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.003 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200502/11 X-Sequence-Number: 10340 > As I read the docs, a temp table doesn't solve our problem, as it does > not persist between sessions. With a web page there is no guarentee > that you will receive the same connection between requests, so a temp > table doesn't solve the problem. It looks like you either have to > create a real table (which is undesirable becuase it has to be > physicaly synced, and TTFB will be very poor) or create an application > tier in between the web tier and the database tier to allow data to > persist between requests tied to a unique session id. > > Looks like the solutions to this problem is not RDBMS IMHO. > > Alex Turner > NetEconomist Did you miss the proposal to store arrays of the found rows id's in a "cache" table ? Is 4 bytes per result row still too large ? If it's still too large, you can still implement the same cache in the filesystem ! If you want to fetch 100.000 rows containing just an integer, in my case (psycopy) it's a lot faster to use an array aggregate. Time to get the data in the application (including query) : select id from temp => 849 ms select int_array_aggregate(id) as ids from temp => 300 ms So you can always fetch the whole wuery results (in the form of an integer per row) and cache it in the filesystem. It won't work if you have 10 million rows though !