Re: PostgreSQL does not choose my indexes well
От | Stephen Frost |
---|---|
Тема | Re: PostgreSQL does not choose my indexes well |
Дата | |
Msg-id | 20200423172048.GF13712@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: PostgreSQL does not choose my indexes well ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | pgsql-performance |
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 index is > > >> smaller. > > > > > Really? The absence of 33 million rows in the partial index seems like > > 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. > > 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
Вложения
В списке pgsql-performance по дате отправления: