Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id E9C0865040C for ; Fri, 12 Dec 2008 14:04:29 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 21457-02 for ; Fri, 12 Dec 2008 14:04:24 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-bw0-f14.google.com (mail-bw0-f14.google.com [209.85.218.14]) by mail.postgresql.org (Postfix) with ESMTP id 3E6A0650419 for ; Fri, 12 Dec 2008 14:04:23 -0400 (AST) Received: by bwz7 with SMTP id 7so3551056bwz.19 for ; Fri, 12 Dec 2008 10:04:22 -0800 (PST) Received: by 10.223.115.16 with SMTP id g16mr4471224faq.93.1229104900937; Fri, 12 Dec 2008 10:01:40 -0800 (PST) Received: by 10.223.125.139 with HTTP; Fri, 12 Dec 2008 10:01:40 -0800 (PST) Message-ID: <4136ffa0812121001x3fde1871t558fd8c58070b7d@mail.gmail.com> Date: Fri, 12 Dec 2008 18:01:40 +0000 From: "Greg Stark" To: "Simon Riggs" Subject: Re: benchmarking the query planner Cc: "Robert Haas" , "Tom Lane" , "Kevin Grittner" , "jd@commandprompt.com" , "Josh Berkus" , "Greg Smith" , pgsql-hackers@postgresql.org In-Reply-To: <1229103209.8673.62.camel@ebony.2ndQuadrant> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <603c8f070812061019r5aca3aajeaa5493b11c5feff@mail.gmail.com> <1229039044.13078.193.camel@hp_dx2400_1> <4136ffa0812111823u645b6ec9wdca60b3da4b00499@mail.gmail.com> <1229072675.13078.196.camel@hp_dx2400_1> <603c8f070812120344m67ef2c1fs41806cfb4ff9e396@mail.gmail.com> <1229093975.13078.275.camel@ebony.2ndQuadrant> <87tz99s7bu.fsf@oxford.xeocode.com> <1229100057.8673.29.camel@ebony.2ndQuadrant> <87hc59s4qx.fsf@oxford.xeocode.com> <1229103209.8673.62.camel@ebony.2ndQuadrant> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200812/971 X-Sequence-Number: 129600 On Fri, Dec 12, 2008 at 5:33 PM, Simon Riggs wrote: >> Incidentally we *do* do block sampling. We pick random blocks and then pick >> random records within those blocks. This was new in, uh, 7.4? 8.0? Sometime >> around then. It dramatically reduced the i/o requirements but there were long >> discussions of how to do it without introducing biases. > > No, we pick random rows. On bigger tables, they get further apart > typically and so we miss any clustering. I mean that we should pick a > random block and read all rows on it. I think what's happening here is that our sampling method is based on the assumption that a records location is not related to its value. Consider a table which is clustered and has two copies of each value. When we look at a block and see n/2 values and we know there are 1000 blocks then a human would conjecture that there are 1000*n/2 distinct values throughout the table and every value is represented twice throughout the whole table. But if we're assuming the records are randomly distributed then looking at the whole block will actually throw us off completely. We'll deduce from the fact that we saw every value twice that there must be hundreds of copies spread throughout the database and there must be a lot less than 1000*n/2 distinct values. I think you need to find two different formulas, one which represents a clustered table and one which represents randomly distributed data. Then you need a way to measure just how clustered the data is so you know how much weight to give each formula. Perhaps comparing the number of duplicates in whole-block samples versus overall random selections would give that measure. -- greg