andrew@tao11.riddles.org.uk writes:
> Given a unique index on (a) and a (slightly higher cost) index on (a,b), the
> query
> select a,b from sometable where a=123;
> will not do an index-only scan unless the allvisfrac is *exactly* 1.0, and
> in the more normal case where only almost all of the pages are all-visible,
> it will generate the plain index scan on a instead, with the extra heap
> fetch.
> This is obviously because cost_index is using ceil(pages_fetched * (1.0 -
> baserel->allvisfrac)), and since this is a 1-row fetch then pages_fetched is
> still 1 after the adjustment for any value of allvisfrac less than exactly
> 1.0.
One idea is to remove the allvisfrac correction from the pages_fetched
calculation altogether, and instead apply it to the I/O cost numbers
at the end, ie
max_IO_cost *= (1.0 - baserel->allvisfrac);min_IO_cost *= (1.0 - baserel->allvisfrac);
just before the partial_path stanza. While that would improve your
particular complaint I'm not sure if it's a good idea in general.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs