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 actu
It appears that in the predicate close (WHERE id IN (foo)), foo cannot
depend on other table (join or other). It must be a list. I anderstand why
(this must be static).
I can build a string value, but in some case, I will have a milion key list.
Postgresql do not have limitation in query size, and
On Fri, Feb 20, 2015 at 11:06 AM, Nicolas Paris wrote:
> Thanks,
>
> I like the idea of partial indexes mixed with simple Views
> So question :
>
> huge_table{
> id,
> field
> }
> CREATE INDEX idx_huge_table ON huge_table(id)
> CREATE INDEX idx_huge_table_for_view1 ON huge_table(id) WHERE id IN (
Thanks,
I like the idea of partial indexes mixed with simple Views
So question :
huge_table{
id,
field
}
CREATE INDEX idx_huge_table ON huge_table(id)
CREATE INDEX idx_huge_table_for_view1 ON huge_table(id) WHERE id IN (1,2,3)
CREATE VIEW view1 AS SELECT * FROM huge_table WHERE id IN (1,2,3)
Do
On Fri, Feb 20, 2015 at 8:28 AM, Nicolas Paris wrote:
> If I replace MV with classical Views, the only indexes that will be used
> will be the huge table's one. As all users will query on the same indexes,
> is will always be loaded in memory, right ? This will be shared, I mean if
> 10 users que
Hello !
I have a huge table, 1 bilion rows, with many indexes.
I have many materialysed view (MV), subsets of this huge table, with same
kind indexes.
I have many users, querying thoses MV.
I have a storage problem, because of MV physical memory use.
I wonder :
If I replace MV with classical View
