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. Thanks, Amit [1] https://www.postgresql.org/message-id/CA%2BTgmoY3LXVUPQVdZW70XKp5PsXffO82pXXt%3DbeegcV%2B%3DRsQgg%40mail.gmail.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
