Hi all,
I have like a repository table with is very very huge with atleast a few
hundreds of millions, may be over that. The information is stored in form of
rows in these tables. I need to make that information wide based on some
grouping and display them as columns on the screen.
I am thinking
On 6/21/05, Amit V Shah [EMAIL PROTECTED] wrote:
Hi all,
...
I am thinking of having a solution where I create views for each screen,
which are just read only.
However, I donot know if the query that creates the view is executed
everytime I select something from the view. Because if that is
Amit V Shah wrote:
Hi all,
I have like a repository table with is very very huge with atleast a few
hundreds of millions, may be over that. The information is stored in form of
rows in these tables. I need to make that information wide based on some
grouping and display them as columns on the
However, I donot know if the query that creates the view is executed
everytime I select something from the view. Because if that is the case,
then I think my queries will again be slow. But if that is the way views
work, then what would be the point in creating them ..
Views are more for
Amit V Shah wrote:
After I sent out this email, I found this article from google
http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html
Looks like we can control as to when the views refresh... I am still kind of
confused, and would appreciate help !!
The create/drop table
] Do Views execute underlying query everytime ??
Amit V Shah wrote:
After I sent out this email, I found this article from google
http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html
Looks like we can control as to when the views refresh... I am still kind
of
confused, and would
From what you say I understand that you have a huge table like this :
( name, value, id )
And you want to make statistics on (value) according to (name,id).
***
First of all a materialized view doen't exist in postgres, it's just a
word to
On 6/21/05, PFC [EMAIL PROTECTED] wrote:
...
In your case I don't think that is the solution, because you do big
updates. With triggers this would mean issuing one update of your
materialized view per row in your big update. This could be slow.
In this case you might want to update the cache
