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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
