>> The temptation is high to estimate the cost of an "index_scan(only) + >> ordered(by ctid) table pages fetch if heap required". (this is what I >> understood from heikki suggestion 3-4. and it makes sense). It may be >> easier to implement both at once but I didn't find the branch in the >> Heikki's git repos. (probably removed since the long time) > > I was thinking about this as well, at least if I understand you
yes. > correctly. That would be similar to a bitmap index scan, and I think > it would be a great thing to have, not only because it would allow us > to get the advantages of index-only scans in situations that are > well-suited to our current bitmap scans, but also because it could be > batched. You could allocate a buffer of work_mem bytes and fill it up > with TIDs; then, when it's full, you sort the buffer and start doing > the necessary heap fetches in physical order. If you still need more > rows, you can clear the buffer and go around for another pass. Issue remaining here is that we don't have 'safe' Indexonly_scan, just indexscan with probability on the 'only'. -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
