Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id A86B12E003A for ; Sun, 2 Dec 2007 08:07:48 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 03247-06 for ; Sun, 2 Dec 2007 08:07:37 -0400 (AST) Received: from oxford.xeocode.com (unknown [87.127.95.196]) by postgresql.org (Postfix) with ESMTP id 69C362E0035 for ; Sun, 2 Dec 2007 08:07:41 -0400 (AST) Received: from localhost.enta.net ([127.0.0.1] helo=oxford.xeocode.com) by oxford.xeocode.com with esmtp (Exim 4.67) (envelope-from ) id 1Iynbm-0002qu-HA; Sun, 02 Dec 2007 12:07:38 +0000 To: "Mindaugas" Cc: Subject: Re: Dealing with big tables In-Reply-To: (Mindaugas's message of "Sun\, 02 Dec 2007 12\:26\:17 +0200 \(EET\)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX.performance" 3428) References: From: Gregory Stark Organization: EnterpriseDB Date: Sun, 02 Dec 2007 12:07:37 +0000 Message-ID: <87r6i5gv06.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/10 X-Sequence-Number: 27826 "Mindaugas" writes: > I execute simple query "select * from bigtable where From='something'". > Query returns like 1000 rows and takes 5++ seconds to complete. As you pointed out that's not terribly slow for 1000 random accesses. It sounds like your drive has nearly 5ms seek time which is pretty common. What exactly is your goal? Do you need this query to respond in under a specific limit? What limit? Do you need to be able to execute many instances of this query in less than 5s * the number of executions? Or do you have more complex queries that you're really worried about? I do have an idea of how to improve Postgres for this case but it has to wait until we're done with 8.3 and the tree opens for 8.4. > Ideas for improvement? Greenplum or EnterpriseDB? Or I forgot something > from PostgreSQL features. Both Greenplum and EnterpriseDB have products in this space which let you break the query up over several servers but at least in EnterpriseDB's case it's targeted towards running complex queries which take longer than this to run. I doubt you would see much benefit for a 5s query after the overhead of sending parts of the query out to different machines and then reassembling the results. If your real concern is with more complex queries they may make sense though. It's also possible that paying someone to come look at your database will find other ways to speed it up. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!