I looked at this a little bit --- it needs proofreading ("VACUUME"?).
Sorry, VACUUME fixed
Do we really need an additional column in pgstat table entries in order to store something that looks like it can be derived from the other columns? The stats tables are way too big already.
It's not derived, because vacuum resets n_inserted_tuples to zero, but it doesn't reset tuples_inserted, tuples_updated and tuples_hot_updated. So, n_inserted_tuples is calculable until first vacuum occurs.
Also, I really think it's a pretty bad idea to make index cost estimation depend on the current state of the index's pending list --- that state seems far too transient to base plan choices on.
I asked for that. v0.23 used statistic data by calling pg_stat_get_fresh_inserted_tuples(), so revert to that.
It's possible to add pending list information to IndexOptInfo, if it's acceptable.
It's particularly got to be nuts to turn off indexscans entirely if the pending list is "too full". Having some lossy pages might not be great but I don't believe it can be so bad that you should go to a seqscan all the time.
It's impossible to return "lossy page" via amgettuple interface. Although, with amgetbitmap it works well - and GIN will not emit error even bitmap becomes lossy.
In attached version, gincostestimate will disable index scan if estimation of number of matched tuples in pending list is greater than non-lossy limit of tidbitmap. That estimation is a product of indexSelectivity and number of tuples in pending list.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
fast_insert_gin-0.26.gz
Description: Unix tar archive
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
