Anastasia Lubennikova <lubennikovaav@gmail.com> writes:
> There is a problem of slow counting in PostgreSQL [1]. The reason why this
> is slow is related to the *MVCC* implementation in PostgreSQL. Index-only
> scans (implemented since PostgreSQL-9.2) providing some performance
> improvements where the *visibility map* of the table allows it. That’s
> good. But it works only for access methods which provide amgettuple method.
> Unfortunately GIN supports only BitmapIndexScan and has no implementation
> of index_getnext() interface [2].
Right ...
> As a GSoC student I will create new Node “Bitmap Index-Only Scan”, which
> would catch tuples from Bitmap Index Scan node and pass them to Aggregate
> node. Thus, new query plan will be as follow:
I'm pretty hesitant about adding a whole new plan node type (which will
require quite a lot of infrastructure) for such a narrow use-case.
I think the odds are good that if you proceed down this path, you will
end up with something that never gets committed to Postgres.
I wonder whether it'd be possible to teach GIN to support index_getnext
instead. Initially it would probably work only for cases where the
index didn't have to return any columns ... but if we did it, maybe the
door would be open to cases where GIN could reconstruct actual values.
regards, tom lane
