Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j3UVX-0005mk-DU for pgsql-performance@arkaria.postgresql.org; Mon, 17 Feb 2020 00:43:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j3UVW-00041b-6H for pgsql-performance@arkaria.postgresql.org; Mon, 17 Feb 2020 00:43:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j3UVV-000419-PP for pgsql-performance@lists.postgresql.org; Mon, 17 Feb 2020 00:43:29 +0000 Received: from aibo.runbox.com ([91.220.196.211]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j3UVP-00076R-EM for pgsql-performance@lists.postgresql.org; Mon, 17 Feb 2020 00:43:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Transfer-Encoding:Content-Type:MIME-Version: Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=ZzsSRAgRT8RZB8IptCr6NajAqVYSWl1oiPbE6hSLpow=; b=IRQirAOxzAKO/xyCYT0C166I8H AEQa1RdYLdrMc4sXdqVO3w78KYsZUuQmuMw7XRX53Xr9tqDNnBUhlM3WhqiEaRd3H+cyQa9g1zzrl CEptXrhqYp9YwfkCjNfQwz6tFP+2VM+kB4CyOV2Stv0evPiTCux6GZVHiGmRa0t4pwZMkiq0hpkUd 9wl9vfAM3if6E5500OVZO/fcGGpJMTO6W/zrXO16K6/RgNa5Vq+tJbo6Ale2fWA1XSxCeHV0p4gZF ZM4a/mvA1n8FdBgjmXxJn9b3AXNW0zn3yK1v519lXvgeg89LrLitu8eDUJnNyaIXDFYowZztPL9aM IPLjnmcg==; Received: from [10.9.9.204] (helo=mailfront22.runbox) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1j3UVM-0007Ee-8y; Mon, 17 Feb 2020 01:43:20 +0100 Received: by mailfront22.runbox with esmtpsa [Authenticated alias (300526)] (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) id 1j3UVH-0005Rx-1a; Mon, 17 Feb 2020 01:43:15 +0100 From: "Mike Sofen" To: "'Tom Lane'" , "'Laurenz Albe'" Cc: "'MingJu Wu'" , References: <43b329d274c3535c75d2fbd6912b5ae8e3e51582.camel@cybertec.at> <19549.1581867005@sss.pgh.pa.us> In-Reply-To: <19549.1581867005@sss.pgh.pa.us> Subject: RE: Partial index creation always scans the entire table Date: Sun, 16 Feb 2020 16:43:10 -0800 Message-ID: <05fc01d5e52b$3c3d1c50$b4b754f0$@runbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFMW+IMoTZ40yevL38K0RgFgHCNdgEI1vSbAl1oe5OpFmoxYA== Content-Language: en-us List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk >From: Tom Lane Sent: Sunday, February 16, 2020 7:30 AM >I've seen people try to do this before. I wonder if the manual page about partial indexes should explicitly say "don't do that". > regards, tom lane Yes please (seriously). The utter beauty of Postgres is the flexibility and power that its evolutionary path has allowed/created. The tragic danger is that the beauty is fairly easy to misapply/misuse. Caveats in the documentation would be very beneficial to both seasoned practitioners and newcomers - it is quite challenging to keep up with everything Postgres and the documentation is where most of us turn for guidance. And thank you Tom (and others), for your willingness to share these (and many, many other) insights - it is so powerful when facts connect with database reality. Mike Sofen