Date: Thu, 23 Apr 2020 13:20:48 -0400
From: Stephen Frost <sfrost@snowman.net>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Thomas Kellerer <shammat@gmx.net>,
	"pgsql-performance@lists.postgresql.org"
 <pgsql-performance@lists.postgresql.org>
Subject: Re: PostgreSQL does not choose my indexes well
Message-ID: <20200423172048.GF13712@tamriel.snowman.net>
References: <35dc90d6-e0c2-13b8-3184-e3db5d854a78@gmail.com>
 <1bb37a19-77f6-8c49-073e-ed6251c98583@gmx.net>
 <CAKFQuwY9twbudMDvmuo+9Mjy0y-cJcvzPazD07-oB+WV1qOMnA@mail.gmail.com>
 <4315.1587655779@sss.pgh.pa.us>
 <CAKFQuwZ5FmpgQQOmUCWu0MmJNuoW+KM_y-Q3YhRaAKVXi58vXg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="HQlzZjkW3WBfUQCF"
Content-Disposition: inline
In-Reply-To: 
 <CAKFQuwZ5FmpgQQOmUCWu0MmJNuoW+KM_y-Q3YhRaAKVXi58vXg@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--HQlzZjkW3WBfUQCF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* David G. Johnston (david.g.johnston@gmail.com) wrote:
> On Thu, Apr 23, 2020 at 8:29 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > "David G. Johnston" <david.g.johnston@gmail.com> writes:
> > > On Thursday, April 23, 2020, Thomas Kellerer <shammat@gmx.net> wrote:
> > >> Plus: scanning idx_tabla_entidad is more efficient because that inde=
x is
> > >> smaller.
> >
> > > Really?  The absence of 33 million rows in the partial index seems li=
ke
> > it
> > > would compensate fully and then some for the extra included columns.
> >
> > On the other hand, an indexscan is likely to end up being effectively
> > random-access rather than the purely sequential access involved in
> > a seqscan.
>=20
> I feel like I'm missing something as the OP's query is choosing indexscan=
 -
> just it is choosing to scan the full index containing the searched upon
> field instead of a partial index that doesn't contain the field but whose
> predicate matches the where condition - in furtherance of a count(*)
> computation where the columns don't really matter.

The actual query isn't a count(*) though, it's a 'select *'.

> I do get "its going to perform 1.4 million random index entries and heap
> lookup anyway - so it doesn't really matter" - but the first answer was
> "the full index is smaller than the partial" which goes against my
> intuition.

Yeah, I'm pretty sure the full index is quite a bit bigger than the
partial index- see my note from just a moment ago.

> The sequential scan that isn't being used would have to touch 25x the
> number of records - so its non-preference seems reasonable.

Agreed on that.

Thanks,

Stephen

--HQlzZjkW3WBfUQCF
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJeoc5vAAoJEO1sijiDR2RVXJQQAJiOQT4HjnjGmZdzS8//W3fd
bYNpNe6NwYesfSHeC2JzEfgjytBz0oU1LVvmcN9EdRdcetT9HfG0UCSAD6yjqn8D
Pw4sUzGkDNUb522IEmkcpoGDh0l7ZsYp0lrxIGF83vwJ5wJIQ/j/RtYjli8jjuPi
5s/uFG382Mq+18WAkYlqZgamjzjrOXUnVwiAp9hTETmciEKOb5SgvxSnjaR3jB84
nTrrxgPNcpxotiwPl+oOuO8gUW5LKMdiDrjD9ai3Rm1aJgoTwAZku+seec5LmM0N
Alg+QDm2An8JbWemT0JjeJPqAJXgP/57Fs1xhNzyFiq2lzM3H8adK/Hw8VXOWUWb
3V2O6jQFkxehCw6mTEA7cUjXgo8UBy8Z1pIDXyPiRyYLs+M9SP0xZ0AZmbkz7Zcl
Uyl22FYv5UC3fUB28gPeI8MbFHlD6GRNVyJvJes4MY0Q86DVfWflTJuUqFs2LUpN
FgyE6/WP6po5O3g6EL2AtVUBIMPiYjhEUwpcckIyqw3Eh4L8PuBTNO734nRNcos5
VzWsEtV+9KmNOls/rbiV32JIqdDtFtj20VSMcdBz4VZ80k/XWMlS4oKLSA1KkRpp
vprIjeFjVo5bWXVpx5UCDCqFv6czgUimsND/nUbgoDqbjLfPw8g+tYmB/nSWxHFn
uojZ/fhkl30Wp28oV/vr
=cg+P
-----END PGP SIGNATURE-----

--HQlzZjkW3WBfUQCF--