I think Gokul was asking because he wanted to work on it, but wanted to
check community approval first.
Yes the problem is that we need to come to a consensus on broken data types. As Heikki pointed out, those data types, which is based on a unstable function like time, date, random etc. This is definitely a theoretical possibility, but still we want to continue building indexes which supports these features. If we can take a decision regarding this, we can have a feature like IOT..
> There's many tricks like column-oriented storage, compression,
> index-organised-tables etc. that would be nice to have. Whether any
> particular feature is worthwhile in the end, the devil is in the details.
Please consider my following statements from a database tuner perspective. I don't want to discourage the visibility map feature, but it has the disadvantages, which we already discussed. While i do a explain analyze and i see 300 reads, but the same query in production might lead to 400 reads(with all the extra 100 being random i/os), because of the state of the visibility map. If there is a long batch job running somewhere in the database, it will affect almost all the visibility maps of the relation. So how can a person, tune and test a query in dev and put it in production and be confident about the i/o performance ? Say Visibility map goes into core after 9.x, the performance of those databases will be less compared to the previous release in these circumstances.
All i am trying to say is that the visibility map has cases, where it will be ineffective and are we deciding to find solutions in those cases.
Thanks,
Gokul.
