Re: A thought on Index Organized Tables

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