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 ED0BA3A589F for ; Wed, 26 Jan 2005 13:48:18 +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 19144-09 for ; Wed, 26 Jan 2005 13:48:05 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by svr1.postgresql.org (Postfix) with ESMTP id 8BAD83A5801 for ; Wed, 26 Jan 2005 13:48:05 +0000 (GMT) Received: by wproxy.gmail.com with SMTP id 71so51775wra for ; Wed, 26 Jan 2005 05:47:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=CTpsSkVu2vYa1GB5ky4Als6cYheGgdYqTxgeWB6hUYpj2P8kGTn8cwoDLlnPzCaLWkYaXvA34tXrvSC6csQ1qRZ+7v3wxw/rHXPiBGLqQ17CEKhZDv3Y7Xm6H3OFfHqPsQOXWEg4R3PpThntivOJ8yHExjC4oxnIYwOulxkFu/0= Received: by 10.54.33.31 with SMTP id g31mr232241wrg; Wed, 26 Jan 2005 05:47:33 -0800 (PST) Received: by 10.54.18.72 with HTTP; Wed, 26 Jan 2005 05:47:32 -0800 (PST) Message-ID: <33c6269f05012605473319ef40@mail.gmail.com> Date: Wed, 26 Jan 2005 08:47:32 -0500 From: Alex Turner Reply-To: alex@neteconomist.com To: Andrei Bintintan Subject: Re: [SQL] OFFSET impact on Performance??? Cc: Greg Stark , Richard Huxton , pgsql-sql@postgresql.org, pgsql-performance@postgresql.org In-Reply-To: <015a01c5038f$73a70720$0b00a8c0@forge> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.04 tagged_above=0 required=5 tests=AWL, RCVD_BY_IP X-Spam-Level: X-Archive-Number: 200501/497 X-Sequence-Number: 10187 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 On Wed, 26 Jan 2005 12:11:49 +0200, Andrei Bintintan wrote: > The problems still stays open. > > The thing is that I have about 20 - 30 clients that are using that SQL query > where the offset and limit are involved. So, I cannot create a temp table, > because that means that I'll have to make a temp table for each session... > which is a very bad ideea. Cursors somehow the same. In my application the > Where conditions can be very different for each user(session) apart. > > The only solution that I see in the moment is to work at the query, or to > write a more complex where function to limit the results output. So no > replace for Offset/Limit. > > Best regards, > Andy. > > > ----- Original Message ----- > From: "Greg Stark" > To: > Cc: "Richard Huxton" ; "Andrei Bintintan" > ; ; > > Sent: Tuesday, January 25, 2005 8:28 PM > Subject: Re: [PERFORM] [SQL] OFFSET impact on Performance??? > > > > > > Alex Turner writes: > > > >> I am also very interesting in this very question.. Is there any way to > >> declare a persistant cursor that remains open between pg sessions? > >> This would be better than a temp table because you would not have to > >> do the initial select and insert into a fresh table and incur those IO > >> costs, which are often very heavy, and the reason why one would want > >> to use a cursor. > > > > TANSTAAFL. How would such a persistent cursor be implemented if not by > > building a temporary table somewhere behind the scenes? > > > > There could be some advantage if the data were stored in a temporary table > > marked as not having to be WAL logged. Instead it could be automatically > > cleared on every database start. > > > > -- > > greg > > > > > >