Re: Add min and max execute statement time in pg_stat_statement
| От | Magnus Hagander |
|---|---|
| Тема | Re: Add min and max execute statement time in pg_stat_statement |
| Дата | |
| Msg-id | CABUevEz042juVie6CbBjRen-b09L2sZ7Ac4NuOJvHDA_L9VNXw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Add min and max execute statement time in pg_stat_statement (KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>) |
| Список | 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:Oh, all right.
> 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.I don't know about it. But I think Windows cache feature is stupid.
> We do assume that the OS is smart enough to keep
> a frequently-read file in cache ... is Windows too stupid for that?
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 по дате отправления: