Hi! I've played with patch. I observe that in some expected scenarios it reduces read buffers significantly.
> 14 февр. 2018 г., в 0:04, Michail Nikolaev <michail.nikol...@gmail.com> > написал(а): > Patch updated + rebased on master. check-world is passing. Minor spots: There are some trailing whitespaces at line ends > Offset cannot be optimized because parallel execution I'd replace with > Offset cannot be optimized [in spite of | due to] parallel execution More important thing: now nodeindexonlyscan.c and nodeindexscan.c share more similar code and comments. I do not think it is strictly necessary to avoid, but we certainly have to answer the question: Is it possible to refactor code to avoid duplication? Currently, patch is not invasive, touches only some relevant code. If refactoring will make it shotgun-suregery, I think it is better to avoid it. > Still not sure about questions 0, 2, 3, 4, 5, and 6 from initial mail (about > explain, explain analyze, documentation and optimiser). I think that I'd be cool if EXPLAIN ANALYZE printed heap fetch information if "Index-Only" way was used. But we already have this debug information in form of reduced count in "Buffers". There is nothing to add to plain EXPLAIN, in my opinion. From my point of view, you should add to patch some words here https://www.postgresql.org/docs/current/static/indexes-index-only-scans.html and, if patch will be accepted, here https://wiki.postgresql.org/wiki/Index-only_scans I do not know if it is possible to take into account this optimization in cost estimation. Does Limit node take cost of scanning into startup cost? Thanks! Best regards, Andrey Borodin.
