Search Postgresql Archives

Re: view or index to optimize performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



thanks for the help

>What you could do is partition the table so that critical information is
>stored in a smaller table while everything else goes to a larger table.

I was thinking the other way round - maybe I can split the large table by
creating a materialized view. But than I read that it is maybe unnecessary
to create a materialized view because pg 

"Materialized views sound a useful workaround, if your database doesn't have
a query cache. If you do have a query cache, then you already effectively
have eager or lazy materialized views (depending on your isolation level):
Just use your normal view (or query) and let the database figure it out."
Quote from Farce Pest in
http://spyced.blogspot.com/2005/05/materialized-views-in-postgresql.html

But later in the same blog it seems to indicate that there is a choice to
either use or not use the query cache of pg.

So I don't know now how this cache works and whether it could help me in
this.

SWK



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux