From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Fujii Masao' <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: reloption to prevent VACUUM from truncating empty pages at the end of relation |
Date: | 2018-04-19 05:32:44 |
Message-ID: | 0A3221C70F24FB45833433255569204D1F944A89@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: Fujii Masao [mailto:masao(dot)fujii(at)gmail(dot)com]
> a very long time before accessing to the relation. Which would cause the
> response-time spikes, for example, I observed such spikes several times
> on
> the server with shared_buffers = 300GB while running the benchmark.
FYI, a long transaction took about 900 ms, while the average transaction response time was 150 ms or so. (I'm working with Fujii-san in this performance benchmark.)
> Therefore, I'm thinking to propose $SUBJECT and enable it to avoid such
> spikes
> for that relation.
How about an integer variable to replace the following?
#define REL_TRUNCATE_FRACTION 16
> Also, first of all, if other transactions need to extend the relation
> (i.e., need new pages) as soon as VACUUM truncates the empty pages at the
> end,
> that truncation would not be so helpful for performance. In this case,
> the truncation and extension of the relation are unnecessarily repeated,
> which would decrease the performance. So, to alleviate this situation,
> $SUBJECT is useful, I think.
I wonder if fillfactor=50 would alleviate this situation.
Regards
Takayuki Tsunakawa
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-04-19 05:41:47 | Re: [HACKERS] Runtime Partition Pruning |
Previous Message | Catalin Iacob | 2018-04-19 05:30:08 | Is a modern build system acceptable for older platforms |