Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHW6x-00077a-Cj for pgsql-performance@arkaria.postgresql.org; Wed, 22 Nov 2017 14:34:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHW6w-0003kl-Lv for pgsql-performance@arkaria.postgresql.org; Wed, 22 Nov 2017 14:34:46 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eHW2L-0007D7-Dd for pgsql-performance@lists.postgresql.org; Wed, 22 Nov 2017 14:30:01 +0000 Received: from cloudserver124499.home.net.pl ([188.128.182.39]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eHW2I-0008JQ-1n for pgsql-performance@lists.postgresql.org; Wed, 22 Nov 2017 14:29:59 +0000 Received: from 5-226-122-185.static.ip.netia.com.pl (5.226.122.185) (HELO DESKTOP5IS4FKS) by serwer1372326.home.pl (188.128.182.39) with SMTP (IdeaSmtpServer 0.82) id 4997313b8a70ae38; Wed, 22 Nov 2017 15:29:53 +0100 From: =?iso-8859-2?Q?Artur_Zaj=B1c?= To: Subject: Bad estimates Date: Wed, 22 Nov 2017 15:29:54 +0100 Message-ID: <03b401d3639e$5d7493a0$185dbae0$@ang.com.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: pl Thread-Index: AdNjmY4BO/1NbvVZQ9iUO+V730y+Rw== List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, We have table created like this: CREATE TABLE xyz AS SELECT generate_series(1,10000000,1) AS gs; Now: db=# explain analyze select * from xyz where gs&1=1; QUERY PLAN ---------------------------------------------------------------------------- ----------------------------------- Seq Scan on xyz (cost=0.00..260815.38 rows=68920 width=4) (actual time=0.044..2959.728 rows=5000000 loops=1) Filter: ((gs & 1) = 1) Rows Removed by Filter: 5000000 Planning time: 0.133 ms Execution time: 3340.886 ms (5 rows) And after adding additional clause to WHERE: db=# explain analyze select * from xyz where gs&1=1 and gs&2=2; QUERY PLAN ---------------------------------------------------------------------------- --------------------------------- Seq Scan on xyz (cost=0.00..329735.50 rows=345 width=4) (actual time=0.045..3010.430 rows=2500000 loops=1) Filter: (((gs & 1) = 1) AND ((gs & 2) = 2)) Rows Removed by Filter: 7500000 Planning time: 0.106 ms Execution time: 3176.355 ms (5 rows) And one more clause: newrr=# explain analyze select * from xyz where gs&1=1 and gs&2=2 and gs&4=4; QUERY PLAN ---------------------------------------------------------------------------- ------------------------------- Seq Scan on xyz (cost=0.00..398655.62 rows=2 width=4) (actual time=0.052..3329.422 rows=1250000 loops=1) Filter: (((gs & 1) = 1) AND ((gs & 2) = 2) AND ((gs & 4) = 4)) Rows Removed by Filter: 8750000 Planning time: 0.119 ms Execution time: 3415.839 ms (5 rows) As we can see estimates differs significally from the actual records count - only three clauses are reducing estimated number of records from 10000000 to 2. I noticed that each additional clause reduces the number about 200 times and define DEFAULT_NUM_DISTINCT is responsible for this behaviur. I think that this variable should be lower or maybe estimation using DEFAULT_NUM_DISTTINCT should be done once per table. Artur Zajac