Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TRm2E-00034R-Pi for pgsql-performance@postgresql.org; Fri, 26 Oct 2012 15:41:22 +0000 Received: from mailout-us.gmx.com ([74.208.5.67] helo=mailout-us.mail.com) by makus.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TRm29-0008Ma-H2 for pgsql-performance@postgresql.org; Fri, 26 Oct 2012 15:41:22 +0000 Received: (qmail 8957 invoked by uid 0); 26 Oct 2012 15:41:12 -0000 Received: from 76.255.19.161 by rms-us013 with HTTP Content-Type: text/plain; charset="utf-8" Date: Fri, 26 Oct 2012 11:41:12 -0400 From: "Kevin Grittner" Message-ID: <20121026154112.306890@gmx.com> MIME-Version: 1.0 Subject: Re: Query-Planer from 6seconds TO DAYS To: =?iso-8859-1?Q?=22B=F6ckler_Andreas=22?= ,pgsql-performance@postgresql.org X-Authenticated: #138763884 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: T8r4cIUW3zOlOQ09Lnwh//J+IGRvb0Dw X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201210/314 X-Sequence-Number: 48273 Böckler Andreas wrote: > b) they high seq costs might be true for that table (partition at >    40gb), but not for the rest of the database Seqscan-Costs per >    table would be great. You can set those per tablespace. Again, with about 40 spindles in our RAID, we got about ten times the speed with a sequential scan as random access, and an index scan has to hit more pages (index and heap rather than just the heap), so you can easily shoot yourself in the foot by assuming that accessing a large portion of the table by index is faster. Really, if you stop focusing on what you think the solution is, and provide a more clear statement of your problem, with sufficient datail, you are likely to get a real solution. http://wiki.postgresql.org/wiki/SlowQueryQuestions -Kevin