Re: A thought on Index Organized Tables

Поиск
Список
Период
Сортировка
От Gokulakannan Somasundaram
Тема Re: A thought on Index Organized Tables
Дата
Msg-id 9362e74e1002240020m42bd8fcex95c638a56dba18a@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A thought on Index Organized Tables  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: A thought on Index Organized Tables
Список pgsql-hackers
Дерево обсуждения

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.

В списке pgsql-hackers по дате отправления: