Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 4EB72B60646 for ; Wed, 1 Jun 2011 22:18:25 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 80484-01 for ; Thu, 2 Jun 2011 01:18:18 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-gy0-f174.google.com (mail-gy0-f174.google.com [209.85.160.174]) by mail.postgresql.org (Postfix) with ESMTP id 0C440B60644 for ; Wed, 1 Jun 2011 22:18:17 -0300 (ADT) Received: by gyd10 with SMTP id 10so170575gyd.19 for ; Wed, 01 Jun 2011 18:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=ajz89a4ppHhIOoF6B36RXtS3hDymLS542cswKEWQ1pg=; b=ELyBv0Efc48RzLMsN3KsQbguJrdBHPSSzoeC/pg6Fi7JT7M8NvvB9B9u8SyeGXkW01 qPg80DJBqYU0+DvkfJjNUwNp1h293i7q2WHYNUXF7DQQoG+deD0JI2w1dtDFrJVTPMIU Ko6C7mKJIkeRooIUB3kG9PqA7tv36ZvekCB4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=ry96UTnAIKzMYKIhK7brWwsYY0JUOtAolGN67EudTzRRVtzpssk5bitGPmjgPIbGYu vGy7V0B1X7YPFwRYhBuRUDUYM+/Dt2ux1qYDe93rpzE1HTZUaLd6R+SlIruzcJLypPvz r9UIV4D7pkhJw4NZ9YGGBo2xiNFB8OMgiBZBI= Received: by 10.236.76.137 with SMTP id b9mr170816yhe.63.1306977497853; Wed, 01 Jun 2011 18:18:17 -0700 (PDT) Received: from Duality (65-101-230-181.hlrn.qwest.net [65.101.230.181]) by mx.google.com with ESMTPS id i61sm79253yhe.19.2011.06.01.18.18.15 (version=SSLv3 cipher=OTHER); Wed, 01 Jun 2011 18:18:16 -0700 (PDT) From: "mark" To: "'Robert James'" Cc: References: In-Reply-To: Subject: Re: CLUSTER versus a dedicated table Date: Wed, 1 Jun 2011 19:18:09 -0600 Message-ID: <005b01cc20c2$f041f360$d0c5da20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwguN4lNLDz5qK0Tz2GqAyaVZhw/AABtlWQ Content-Language: en-us X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.551 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RFC_ABUSE_POST=0.001 X-Spam-Level: X-Archive-Number: 201106/12 X-Sequence-Number: 43945 > -----Original Message----- > From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance- > owner@postgresql.org] On Behalf Of Robert James > Sent: Wednesday, June 01, 2011 5:55 PM > To: pgsql-performance@postgresql.org > Subject: [PERFORM] CLUSTER versus a dedicated table > > Hi. I'm interested in understanding the differences between > CLUSTERing a table and making a dedicated one. > > We have a table with about 1 million records. On a given day, only > about 1% of them are of interest. That 1% changes every day (it's > WHERE active_date = today), and so we index and cluster on it. > > Even so, the planner shows a very large cost for the Index Scan: about > 3500. If I instead do a SELECT INTO temp_table FROM big_table WHERE > active_date = today, and then do SELECT * FROM temp_table, I get a > planned cost of 65. Yet, the actual time for both queries is almost > identical. > > Questions: > 1. Why is there such a discrepancy between the planner's estimate and > the actual cost? > > 2. In a case like this, will I in general see a performance gain by > doing a daily SELECT INTO and then querying from that table? My ad hoc > test doesn't indicate I would (despite the planner's prediction), and > I'd rather avoid this if it won't help. > > 3. In general, does CLUSTER provide all the performance benefits of a > dedicated table? If it doesn't, what does it lack? > > Thank you. Start here: http://wiki.postgresql.org/wiki/SlowQueryQuestions 1: there could be many reasons for the planner to come up a grossly inaccurate ESTIMATE for some values. Last time the table was analyzed, is usually where people start. 2: look at table partitioning it's pretty straight forward and sounds like it might be a good fit for you. It will however involve some triggers or rules and check constraints. Table partitioning has some downsides though, you should be aware of what they are before you commit to it. 3: clustering, from a high level, just reorders the data on disk by a given index. Depending on your setup keeping it close to that clustered ordering might be trivial or it might not be. Big tables are relative to different people, 1M rows might be a big table or it might not be, since you didn't post the size of the table and indexes we can only guess. Table partitioning helps most with table maintenance, IMO, but can be very useful it the constraint exclusion can eliminate a large number of child tables right off so it doesn't have to traverse large indexes or do lots of random IO. You will need to post at lot more specific info if you want more specific help. The guide to reporting slow queries or guide to reporting problems and start gathering specific information and then post back to the list. -Mark > > -- > Sent via pgsql-performance mailing list (pgsql- > performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance