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 DE2963A488D for ; Thu, 20 Jan 2005 16:48:05 +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 45016-02 for ; Thu, 20 Jan 2005 16:47:56 +0000 (GMT) Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.250.190.2]) by svr1.postgresql.org (Postfix) with ESMTP id A97EB3A1CF7 for ; Thu, 20 Jan 2005 16:47:55 +0000 (GMT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id B74C8319C3; Thu, 20 Jan 2005 17:47:54 +0100 (MET) From: Ron Mayer X-Newsgroups: pgsql.performance Subject: Re: [SQL] OFFSET impact on Performance??? Date: Thu, 20 Jan 2005 08:49:39 -0800 Organization: Hub.Org Networking Services Lines: 23 Message-ID: <41EFE123.9020209@cheapcomplexdevices.com> References: <019f01c4fee1$1b58d600$0b00a8c0@forge> <41EF9FD3.5020400@archonet.com> <020d01c4fef6$595bb9d0$0b00a8c0@forge> <41EFCC5B.5010302@archonet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org To: Richard Huxton User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en In-Reply-To: <41EFCC5B.5010302@archonet.com> To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200501/317 X-Sequence-Number: 10007 Richard Huxton wrote: > > If you've got a web-application then you'll probably want to insert the > results into a cache table for later use. > If I have quite a bit of activity like this (people selecting 10000 out of a few million rows and paging through them in a web browser), would it be good to have a single table with a userid column shared by all users, or a separate table for each user that can be truncated/dropped? I started out with one table; but with people doing 10s of thousand of inserts and deletes per session, I had a pretty hard time figuring out a reasonable vacuum strategy. Eventually I started doing a whole bunch of create table tmp_XXXX tables where XXXX is a userid; and a script to drop these tables - but that's quite ugly in a different way. With 8.0 I guess I'll try the single table again - perhaps what I want may be to always have a I/O throttled vacuum running... hmm. Any suggestions?