flyusa2010 fly wrote:
> Thanks for your reply.
> Yes, i mean disk may lie to os.
Our documentation covers this extensively:
http://www.postgresql.org/docs/9.0/static/wal-reliability.html
---
>
>
> On Fri, Dec 3,
Thanks for your reply.
Yes, i mean disk may lie to os.
On Fri, Dec 3, 2010 at 12:14 PM, Stefan Kaltenbrunner
wrote:
> On 12/03/2010 06:43 PM, Heikki Linnakangas wrote:
>
>> On 03.12.2010 13:49, flyusa2010 fly wrote:
>>
>>> When writing log, dbms should synchronously flush log to disk. I'm
>>> w
On 12/03/2010 06:43 PM, Heikki Linnakangas wrote:
On 03.12.2010 13:49, flyusa2010 fly wrote:
When writing log, dbms should synchronously flush log to disk. I'm
wondering, if it is possible that the logs are in disk cache, while the
control is returned to dbms again, so dbms thinks logs are persi
On 03.12.2010 13:49, flyusa2010 fly wrote:
When writing log, dbms should synchronously flush log to disk. I'm
wondering, if it is possible that the logs are in disk cache, while the
control is returned to dbms again, so dbms thinks logs are persistent on
disk. In this case, if the disk fails, the
When writing log, dbms should synchronously flush log to disk. I'm
wondering, if it is possible that the logs are in disk cache, while the
control is returned to dbms again, so dbms thinks logs are persistent on
disk. In this case, if the disk fails, then there's incorrectness for dbms
log writing,
mac_man2...@yahoo.it wrote:
Since I am interested just in work_mem variations, I should prevent
each query to take advantages from revious executions of the 22
queries them selves. For example, taking cache advantages.
work_mem has nothing to do with disk caching; it controls whether larger
s
Hi to all.
I am trying to see how PostgreSQL performance changes on the basis of
work_mem. So, I am going to execute the 22 queries of TPCH
(http://www.tpc.org/tpch/) again and again, each time for a different
value of work_mem.
Since I am interested just in work_mem variations, I should preve
