Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 1B96B6336F9 for ; Sat, 9 Jan 2010 08:18:18 -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 19331-07 for ; Sat, 9 Jan 2010 12:18:07 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mail.postgresql.org (Postfix) with ESMTP id 526226336EB for ; Sat, 9 Jan 2010 08:18:07 -0400 (AST) Received: by bwz5 with SMTP id 5so12855429bwz.3 for ; Sat, 09 Jan 2010 04:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Ti031wwW/WTfIY+xtyoPeGcfyDqa1Me/YyQEJTwMpFM=; b=RpCiMLe0RQ8M/4ktU9MkxkEQS+zc2T6mKG8cmb2Kt3GMn64PMuRjtZzVtmAVE3n5kk 3dn/cTbQWp1AvpGr0N5KLgvt1yyyr8kc0DX3uwBOyYcGqi4InOvPYvc1Jixqq5T3xjq6 5mYxi+yqJPjeJw/hYWRaadUaaiSSIF64qeIjI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eT3nGL+o/OFUKRxJn4I97UEOEynGPAWtXf0MZAwmOSH08mRM0rllsDxU4BH0x6o8/8 6TPwUEs9AELXbTTEKRal4yST4CN6uDxVDB+EdcK9e+80/D7m8VA3ujOX/wS39fZbcvDc UZNHIxGuJ8oiUr+AH4Ub/8MOf0/Kd4opUgX1o= MIME-Version: 1.0 Received: by 10.204.0.70 with SMTP id 6mr1354267bka.85.1263039484495; Sat, 09 Jan 2010 04:18:04 -0800 (PST) In-Reply-To: <4B485975.70506@zhukcity.ru> References: <4B485975.70506@zhukcity.ru> Date: Sat, 9 Jan 2010 12:18:04 +0000 Message-ID: <2f4958ff1001090418i78dee992t5ff2d78a54187c07@mail.gmail.com> Subject: Re: PG optimization question From: =?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= To: Nickolay Cc: pgsql-performance@postgresql.org Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.589 tagged_above=-10 required=5 tests=BAYES_00=-2.599, FH_DATE_PAST_20XX=3.188 X-Spam-Level: X-Archive-Number: 201001/159 X-Sequence-Number: 37039 maybe that 'one big table' needs something called 'normalisation' first. See how much that will shed off. You might be surprised. The partitioning needs to be done by some constant intervals, of time - in your case. Whatever suits you, I would suggest to use the rate that will give you both ease of archiving/removal of old data (so not too wide), and also, one that would make sure that most of the data you'll be searching for in your queries will be in one , two partitions per query.