Re: PG 9.3 materialized view VS Views, indexes, shared memory

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: PG 9.3 materialized view VS Views, indexes, shared memory
Дата
Msg-id 54F905A3.7090602@BlueTreble.com
обсуждение исходный текст
Ответ на Re: PG 9.3 materialized view VS Views, indexes, shared memory  (Nicolas Paris <niparisco@gmail.com>)
Ответы Re: PG 9.3 materialized view VS Views, indexes, shared memory
Список pgsql-performance
On 2/20/15 12:09 PM, Nicolas Paris wrote:
> Well it seems that max  query size for CREATE INDEX is 8160 character in
> my 9.3 postgresql version.
> Then the only solution see is to add  a new boolean field : huge_table.view1
> and change predicat to "WHERE view1=1 "
> But I may have 800 views.. adding 800 new fields indexed to the huge
> table is actually not a good idea. Too bad
>
> Any idea to solve that partial view limitation?

If you have that many different views I doubt you want that many indexes
anyway.

Have you tried just hitting the base table and indexes directly, either
through plain views or just direct SQL?

Also, how frequently does data change in the huge table? This sounds
like a case where the visibility map could make a huge difference.

By the way, if all the Mat Views are in one schema that's already in the
search path, a very easy way to test this would be to create an
equivalent set of regular views in a different schema (which you can
probably do programmatically via pg_get_viewdef()) and then change the
search_path to put the new schema before the old.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: slow server : s_lock and _bt_checkkeys on perf top
Следующее
От: Nicolas Paris
Дата:
Сообщение: Re: PG 9.3 materialized view VS Views, indexes, shared memory