=?iso-8859-1?Q?Klein_Bal=E1zs?= <[EMAIL PROTECTED]> writes:
> 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.
Hm? There is no query cache in PG.
regards, tom lane
---(end of
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
On Wed, Dec 21, 2005 at 10:49:29PM +0100, Klein Bal?zs wrote:
> I thought that if I used a view to retrieve data its content might be cached
> so it would make the query faster.
No. A view is essentially exactly the same as inserting the view
definition into the query that's using it. IE:
CREATE
Klein Balázs wrote:
Hello everybody,
I have a table that stores responses to questions in different
questionnaires. This table will grow to millions of rows.
[snip]
I can store the fact that it is biodata in the bio field - it is biodata if
the value of that field is not 0 and I can index that
I thought that if I used a view to retrieve data its content might be cached
so it would make the query faster.
Am Mittwoch, 21. Dezember 2005 21:27 schrieb Klein Balázs:
> Or should I instead create a view that contains only the biodata and
select
> from that? But will postgres use the indexes th
Am Mittwoch, 21. Dezember 2005 21:27 schrieb Klein Balázs:
> Or should I instead create a view that contains only the biodata and select
> from that? But will postgres use the indexes than? Would that be a better
> approach?
Whether the query is executed by a view or typed in in its full form by h
Hello everybody,
I have a table that stores responses to questions in different
questionnaires. This table will grow to millions of rows.
My problem is that while most of the data in the table are rarely used in
queries one type of response will be used quite often: biodata - name,
gender, e-mail
