From: | Thomas Vatter <thomas(dot)vatter(at)network-inventory(dot)de> |
---|---|
To: | Tino Wildenhain <tino(at)wildenhain(dot)de> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: in memory views |
Date: | 2006-05-10 12:23:49 |
Message-ID: | 4461DB55.3030005@network-inventory.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tino Wildenhain wrote:
> Thomas Vatter schrieb:
>
>> Tino Wildenhain wrote:
>
> ...
>
>>> Well you will need the equally 40 seconds to fill your hypothetical
>>> in memory table. (even a bit more due to the creation of a
>>> datastructure).
>>>
>>> So you can do the aproaches of semi materialized views (that are in
>>> fact
>>> writing into a shadow table) or just prefetch your data at time - just
>>> at the times you would refill your memory tables if they existed.
>>> A cronjob with select/fetch should do.
>>>
>>> Regards
>>> Tino
>>>
>>>
>>
>> If the in memory table is created a bootup time of the dbms it is
>> already present when user selects the data. Of course the challenge
>> is to keep the in memory table up to date if data are changed. What
>> do you mean with semi materialized views, I have tried select * from
>> this_view with the same result. Also, if I repeat the query it does
>> not run faster.
>>
> Semi materialized views are just views with aditional rules and some
> triggers which copy data to another table. There are several receipes
> if you google accordingly.
>
> I do not know what you mean by "bootup time" - do you really reboot
> your database server? *hehe* just kidding ;)
>
> In your first email you told me your query indeed runs faster the 2nd
> time (due to the caching) now you are telling me that it is not.
>
> Btw, judging from your analyze output you are using very cryptic
> table and column names - you can use aliasing in the query and dont
> have to resort to tiny tags when you actually name the objects ;)
>
> Maybe others have comments on your query. Btw, better use
> explain analyze to get realistic results.
>
> Regards
> Tino
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
>
The subsequent rows are shown faster not the subsequent queries - if
you really read my first e-mail ;-) . Yes, I have done analyse
yesterday, the database has not changed, afaik it is necessary when the
database contents are changing.
regards
tom
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Weimer | 2006-05-10 12:44:06 | Re: [PERFORM] Arguments Pro/Contra Software Raid |
Previous Message | Douglas McNaught | 2006-05-10 12:15:22 | Re: Arguments Pro/Contra Software Raid |