Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 7652A6330D3 for ; Sat, 9 Jan 2010 08:59:23 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 24598-04 for ; Sat, 9 Jan 2010 12:59:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from relay1.mail.masterhost.ru (relay1.mail.masterhost.ru [83.222.23.61]) by mail.postgresql.org (Postfix) with ESMTP id EBC2D6329CA for ; Sat, 9 Jan 2010 08:59:12 -0400 (AST) Received: from [UNAVAILABLE] ([80.252.153.64] helo=[192.168.1.2]) by relay1.mail.masterhost.ru with esmtp envelope from authenticated with postmaster@zhukcity.ru message id 1NTauK-000G6t-ML; Sat, 09 Jan 2010 15:59:08 +0300 Message-ID: <4B487D9C.9020507@zhukcity.ru> Date: Sat, 09 Jan 2010 15:59:08 +0300 From: Nickolay User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Kenneth Marshall CC: pgsql-performance@postgresql.org Subject: Re: PG optimization question References: <4B485975.70506@zhukcity.ru> <2f4958ff1001090418i78dee992t5ff2d78a54187c07@mail.gmail.com> <4B4879A0.2060703@zhukcity.ru> <20100109124646.GA8123@it.is.rice.edu> In-Reply-To: <20100109124646.GA8123@it.is.rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SpamTest-Envelope-From: nitro@zhukcity.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 11577 [Jan 09 2010] X-SpamTest-Info: {relay has no DNS name} X-SpamTest-Method: none X-SpamTest-Rate: 40 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.078 tagged_above=-10 required=5 tests=BAYES_05=-1.11, FH_DATE_PAST_20XX=3.188 X-Spam-Level: ** X-Archive-Number: 201001/166 X-Sequence-Number: 37046 That may help with the queries speed (not a problem now), but we'll then have to add UNION statement for daily staging table for other 5% of requests, right? And there would be a moment when daily message is in archive table AND in daily table (while transferring from daily table to archive). Our main problem is in blocking when doing DELETE (app sometimes freezes for a long time), and also we have to do VACUUM on live table, which is not acceptable in our app. Thanks for your reply, I was kinda worried about number of partitions and how this would affect PG query execution speed. Kenneth Marshall wrote: >> Oh, btw, 95% of queries are searching rows for current date (last 24 >> hours). >> > > You may want to use a daily staging table and then flush to the > monthly archive tables at the end of the day. > >