Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mG4CW-0004Lo-Dz for pgsql-performance@arkaria.postgresql.org; Tue, 17 Aug 2021 18:52:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mG4CV-0005ac-Ba for pgsql-performance@arkaria.postgresql.org; Tue, 17 Aug 2021 18:52:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mG4CV-0005aN-0C for pgsql-performance@lists.postgresql.org; Tue, 17 Aug 2021 18:52:39 +0000 Received: from mail-io1-xd29.google.com ([2607:f8b0:4864:20::d29]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mG4CS-0005wT-J4 for pgsql-performance@lists.postgresql.org; Tue, 17 Aug 2021 18:52:38 +0000 Received: by mail-io1-xd29.google.com with SMTP id b7so20009349iob.4 for ; Tue, 17 Aug 2021 11:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=cYDXJ0+KtF2nIHh+OEVX4aVUcCQRaRhnIoD30SNHSlg=; b=Lrrr4mLeVV9nCvjkOy9yxE/25LgWeZXqDcwyGsHc5QdVStYtEIG3WU8q+Q0ut5y8Nj tLxpc4pD5pW0o/GGuDj6eluJCNrNOZQVG/7sPzjwMgRXMb9dRSKMsCdNrrdT2qSzrf4g 1xy9rYTZi2iafRIGRHKzgMH9mnu9h510cydzdhXORtN87YMe1Y+NStMONvBLp1KTC6Qw iBzRDPwm9NPbEXVtbLQp+agLbG71Mr7JJ/k1TYNIXnz0AEBPPFL8g6c4ZbwEO4nuBirS oEnrQcdVHF4vEA582g6QreE9o728vEo2yrQEd7roJf5unZ3pxOt7A/YD3QeB0RJVivPo Bimw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=cYDXJ0+KtF2nIHh+OEVX4aVUcCQRaRhnIoD30SNHSlg=; b=Xl3BSJDK33nkEthtISpsZIizbpkuo0DGxvU2PSiWe+adQSfxrNW8R2qSl78SYNvuhN 9Q2cIOPty9RiBneJlgwtjsxEPkHhtJr5Byhtt/IqL54UQDsGULAAeMFI4K0078Vcd2XW oI9JapkIqBrrrky37PaGzXq04BsdGmpZkfNra3p9y51O7FQCq2Slf4csKNULVDE1Hzfq nTH0uU6B+zINzxs/QvQxPKGeOUG0ffVS2OTezehDGJxtm0uCiXlIMmPclwoTNioANQ0P upgSdn5T6ek8yTK6ydYmZU70fBjTxaroAGhgE/lt/dwLBErZ+8vphbQnREYhmsAMhens UT5A== X-Gm-Message-State: AOAM531xG+7Lqt8pjbrxhVNh+tGhaK3p+6tDOjxdBQBAoG5ZowlK5hIC Lip7O6FR+ONf1fNYHpQnPPLgQw== X-Google-Smtp-Source: ABdhPJz5R3uqfFiIiJWWLVrJINBHLfRt4ZI+WXmXSNekXBIbT8EYWjyiyv9121sCA91F9eg+YIhGfA== X-Received: by 2002:a05:6602:2211:: with SMTP id n17mr3950147ion.142.1629226354700; Tue, 17 Aug 2021 11:52:34 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id z26sm1524613iol.6.2021.08.17.11.52.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Aug 2021 11:52:33 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id C8FC38009E1; Tue, 17 Aug 2021 13:52:32 -0500 (CDT) Date: Tue, 17 Aug 2021 13:52:32 -0500 From: Justin Pryzby To: Matt Dupree Cc: pgsql-performance@lists.postgresql.org Subject: Re: Postgres using the wrong index index Message-ID: <20210817185232.GN10479@telsasoft.com> References: <20210811123856.GE10479@telsasoft.com> <20210812034510.GG10479@telsasoft.com> <20210812232006.GN10479@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Aug 16, 2021 at 11:22:44AM -0400, Matt Dupree wrote: > > Is either half of the AND estimated correctly? If you do a query > > with only ">=", and a query with only "<=", do either of them give an > > accurate rowcount estimate ? > > Dropping >= results in the correct index being used. Dropping <= doesn't > have this effect. This doesn't answer the question though: are the rowcount estimes accurate (say within 10%). It sounds like interpolating the histogram is giving a poor result, at least over that range of values. It'd be interesting to see the entire histogram. You might try increasing (or decreasing) the stats target for that column, and re-analyzing. Your histogram bounds are for ~38 months of data, and your query is for the previous month (July). $ date -d @1530186399 Thu Jun 28 06:46:39 CDT 2018 $ date -d @1629125609 Mon Aug 16 09:53:29 CDT 2021 $ date -d @1627369200 Tue Jul 27 02:00:00 CDT 2021 $ date -d @1624777200 Sun Jun 27 02:00:00 CDT 2021 The timestamp column has ndistinct near -1, similar to a continuous distribution, so I'm not sure why the estimate would be so bad. -- Justin