Re: Add min and max execute statement time in pg_stat_statement - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Add min and max execute statement time in pg_stat_statement
Date
Msg-id CABUevEz042juVie6CbBjRen-b09L2sZ7Ac4NuOJvHDA_L9VNXw@mail.gmail.com
Whole thread Raw
In response to Re: Add min and max execute statement time in pg_stat_statement  (KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>)
List pgsql-hackers
On Wed, Jan 29, 2014 at 9:03 AM, KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp> wrote:
(2014/01/29 15:51), Tom Lane wrote:
> KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp> writes:
>> By the way, latest pg_stat_statement might affect performance in Windows system.
>> Because it uses fflush() system call every creating new entry in
>> pg_stat_statements, and it calls many fread() to warm file cache.
> This statement doesn't seem to have much to do with the patch as
> committed.  There are no fflush calls, and no notion of warming the
> file cache either.
Oh, all right.

> We do assume that the OS is smart enough to keep
> a frequently-read file in cache ... is Windows too stupid for that?
I don't know about it. But I think Windows cache feature is stupid.
It seems to always write/read data to/from disk, nevertheless having large memory...
I'd like to know test result on Windows, if we can...


I am quite certain the Windows cache is *not* that stupid, and hasn't been since the Windows 3.1 days.

If you want to make certain, set  FILE_ATTRIBUTE_TEMPORARY when the file is opened, then it will work really hard not to write it to disk - harder than most Linux fs'es do AFAIK. This should of course only be done if we don't mind it going away :)

As per port/open.c, pg will set this when O_SHORT_LIVED is specified. But AFAICT, we don't actually use this *anywhere* in the backend? Perhaps we should for this - and also for the pgstat files?

(I may have missed a codepath, only had a minute to do some greping)


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Next
From: Kouhei Kaigai
Date:
Subject: Re: Triggers on foreign tables