> > > 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.
