On Thu, Jun 22, 2017 at 11:12 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/06/22 10:01, Michael Paquier wrote: >> #3 implies that the index AM logic is implemented in the table >> AM. Not saying that it is not useful, but it does not feel natural to >> have the planner request for a sequential scan, just to have the table >> AM secretly do some kind of index/skipping scan. > > I had read a relevant comment on a pluggable storage thread awhile back > [1]. In short, the comment was that the planner should be able to get > some intelligence, via some API, from the heap storage implementation > about the latter's access cost characteristics. The storage should > provide accurate-enough cost information to the planner when such a > request is made by, say, cost_seqscan(), so that the planner can make > appropriate choice. If two tables containing the same number of rows (and > the same size in bytes, perhaps) use different storage implementations, > then, planner's cost parameters remaining same, cost_seqscan() will end up > calculating different costs for the two tables. Perhaps, SeqScan would be > chosen for one table but not the another based on that.
Yeah, I agree that the costing part needs some clear attention and thoughts, and the gains are absolutely huge with the correct interface. That could be done in a later step though. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
