> 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: teodor@sigaev.ru
WWW: http://www.sigaev.ru/