On 2017-07-27 11:53, Sokolov Yura wrote:
On 2017-07-26 20:28, Sokolov Yura wrote:
On 2017-07-26 19:46, Claudio Freire wrote:
On Wed, Jul 26, 2017 at 1:39 PM, Sokolov Yura
wrote:
On 2017-07-24 12:41, Sokolov Yura wrote:
test_master_1/pretty.log
...
time activity tps latency stddev
On Thu, Jul 27, 2017 at 2:10 PM, Alvaro Herrera
wrote:
> Claudio Freire wrote:
>> On Thu, Jul 27, 2017 at 1:46 PM, Alvaro Herrera
>> wrote:
>> > Claudio Freire wrote:
>> >
>> >> > The vacuuming the very large table with no index could also take a
>> >> > long time, and it scans and vacuums blocks
Claudio Freire wrote:
> On Thu, Jul 27, 2017 at 1:46 PM, Alvaro Herrera
> wrote:
> > Claudio Freire wrote:
> >
> >> > The vacuuming the very large table with no index could also take a
> >> > long time, and it scans and vacuums blocks one by one. So I imagined
> >> > that we can vacuum the FSM onc
On Thu, Jul 27, 2017 at 1:46 PM, Alvaro Herrera
wrote:
> Claudio Freire wrote:
>
>> > The vacuuming the very large table with no index could also take a
>> > long time, and it scans and vacuums blocks one by one. So I imagined
>> > that we can vacuum the FSM once vacuumed a certain amount of block
Claudio Freire wrote:
> > The vacuuming the very large table with no index could also take a
> > long time, and it scans and vacuums blocks one by one. So I imagined
> > that we can vacuum the FSM once vacuumed a certain amount of blocks.
> > And that can avoid bloating table during the long-time
On Thu, Jul 27, 2017 at 6:16 AM, Masahiko Sawada wrote:
> On Thu, Jul 27, 2017 at 5:48 PM, Sokolov Yura
> wrote:
>> On 2017-07-27 11:30, Masahiko Sawada wrote:
>>>
>>> On Tue, Jul 25, 2017 at 2:27 AM, Claudio Freire
>>> wrote:
On Mon, Jul 24, 2017 at 2:20 PM, Claudio Freire
wrote
On Thu, Jul 27, 2017 at 5:48 PM, Sokolov Yura
wrote:
> On 2017-07-27 11:30, Masahiko Sawada wrote:
>>
>> On Tue, Jul 25, 2017 at 2:27 AM, Claudio Freire
>> wrote:
>>>
>>> On Mon, Jul 24, 2017 at 2:20 PM, Claudio Freire
>>> wrote:
On Mon, Jul 24, 2017 at 2:10 PM, Sokolov Yura
wrot
On 2017-07-26 20:28, Sokolov Yura wrote:
On 2017-07-26 19:46, Claudio Freire wrote:
On Wed, Jul 26, 2017 at 1:39 PM, Sokolov Yura
wrote:
On 2017-07-24 12:41, Sokolov Yura wrote:
test_master_1/pretty.log
...
time activity tps latency stddev min max
11130 av+ch 198
On 2017-07-27 11:30, Masahiko Sawada wrote:
On Tue, Jul 25, 2017 at 2:27 AM, Claudio Freire
wrote:
On Mon, Jul 24, 2017 at 2:20 PM, Claudio Freire
wrote:
On Mon, Jul 24, 2017 at 2:10 PM, Sokolov Yura
wrote:
On 2017-07-24 19:11, Claudio Freire wrote:
I was mostly thinking about something li
On Tue, Jul 25, 2017 at 2:27 AM, Claudio Freire wrote:
> On Mon, Jul 24, 2017 at 2:20 PM, Claudio Freire
> wrote:
>> On Mon, Jul 24, 2017 at 2:10 PM, Sokolov Yura
>> wrote:
>>> On 2017-07-24 19:11, Claudio Freire wrote:
I was mostly thinking about something like the attached patch.
>>
On 2017-07-26 19:46, Claudio Freire wrote:
On Wed, Jul 26, 2017 at 1:39 PM, Sokolov Yura
wrote:
On 2017-07-24 12:41, Sokolov Yura wrote:
test_master_1/pretty.log
...
time activity tps latency stddev min max
11130 av+ch 198198ms374ms 7ms 1956ms
11160
On Wed, Jul 26, 2017 at 1:39 PM, Sokolov Yura
wrote:
> On 2017-07-24 12:41, Sokolov Yura wrote:
> test_master_1/pretty.log
...
> time activity tps latency stddev min max
> 11130 av+ch 198198ms374ms 7ms 1956ms
> 11160 av+ch 248163ms401ms
On Mon, Jul 24, 2017 at 2:20 PM, Claudio Freire wrote:
> On Mon, Jul 24, 2017 at 2:10 PM, Sokolov Yura
> wrote:
>> On 2017-07-24 19:11, Claudio Freire wrote:
>>> I was mostly thinking about something like the attached patch.
>>>
>>> Simple, unintrusive, and shouldn't cause any noticeable slowdown
On Mon, Jul 24, 2017 at 2:10 PM, Sokolov Yura
wrote:
> On 2017-07-24 19:11, Claudio Freire wrote:
>>
>> On Mon, Jul 24, 2017 at 6:37 AM, Sokolov Yura
>> wrote:
>>>
>>> Good day, Claudio
>>>
>>>
>>> On 2017-07-22 00:27, Claudio Freire wrote:
On Fri, Jul 21, 2017 at 2:41 PM, Sokolov
On Thu, Jul 20, 2017 at 12:51 PM, Tom Lane wrote:
> Robert Haas writes:
> > I think that's a valid point. There are also other concerns here -
> > e.g. whether instead of adopting the patch as proposed we ought to (a)
> > use some smaller size, or (b) keep the size as-is but reduce the
> > maxi
On 2017-07-24 19:11, Claudio Freire wrote:
On Mon, Jul 24, 2017 at 6:37 AM, Sokolov Yura
wrote:
Good day, Claudio
On 2017-07-22 00:27, Claudio Freire wrote:
On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
wrote:
My friend noticed, that I didn't said why I bother with autovacuum.
Our custo
On Mon, Jul 24, 2017 at 6:37 AM, Sokolov Yura
wrote:
> Good day, Claudio
>
>
> On 2017-07-22 00:27, Claudio Freire wrote:
>>
>> On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
>> wrote:
>>>
>>>
>>> My friend noticed, that I didn't said why I bother with autovacuum.
>>> Our customers suffers from ta
On 2017-07-21 20:41, Sokolov Yura wrote:
On 2017-07-21 19:32, Robert Haas wrote:
On Fri, Jul 21, 2017 at 4:19 AM, Sokolov Yura
wrote:
Probably with increased ring buffer there is no need in raising
vacuum_cost_limit. Will you admit it?
No, I definitely won't admit that. With default settin
Good day, Claudio
On 2017-07-22 00:27, Claudio Freire wrote:
On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
wrote:
My friend noticed, that I didn't said why I bother with autovacuum.
Our customers suffers from table bloating. I've made synthetic
bloating test, and started experiments with modi
On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
wrote:
>
> My friend noticed, that I didn't said why I bother with autovacuum.
> Our customers suffers from table bloating. I've made synthetic
> bloating test, and started experiments with modifying micro- and
> auto-vacuum. My first attempts were to
On 2017-07-21 19:32, Robert Haas wrote:
On Fri, Jul 21, 2017 at 4:19 AM, Sokolov Yura
wrote:
Probably with increased ring buffer there is no need in raising
vacuum_cost_limit. Will you admit it?
No, I definitely won't admit that. With default settings autovacuum
won't write more than ~2.3MB
On Fri, Jul 21, 2017 at 4:19 AM, Sokolov Yura
wrote:
> You are one of leadership. I know it is not your job to test every tiny
> change a school boy proposed. But here is a lot of people, who waits for
> your word. Instead of cooling rush and closing discussions, you may just
> say: "please, someo
On 2017-07-20 22:51, Tom Lane wrote:
Robert Haas writes:
I think that's a valid point. There are also other concerns here -
e.g. whether instead of adopting the patch as proposed we ought to (a)
use some smaller size, or (b) keep the size as-is but reduce the
maximum fraction of shared_buffers
On 2017-07-20 20:59, Robert Haas wrote:
If you want something changed, it's your job to do that testing.
I've been testing for two weeks before I wrote to pgsql-hackers. And I
wrote some highlevel results in first letter.
I haven't noticed transactions slowdown from increased vacuum ring
buffe
Robert Haas writes:
> I think that's a valid point. There are also other concerns here -
> e.g. whether instead of adopting the patch as proposed we ought to (a)
> use some smaller size, or (b) keep the size as-is but reduce the
> maximum fraction of shared_buffers that can be consumed, or (c) di
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jul 20, 2017 at 3:04 PM, Stephen Frost wrote:
> > I agree that it's a common problem for VACUUM to go too fast, or for
> > VACUUM to go too slow, but that's really what the vacuum_cost_limit
> > mechanism is for.
>
> I think that's a valid po
On Thu, Jul 20, 2017 at 3:04 PM, Stephen Frost wrote:
> I agree that it's a common problem for VACUUM to go too fast, or for
> VACUUM to go too slow, but that's really what the vacuum_cost_limit
> mechanism is for.
I think that's a valid point. There are also other concerns here -
e.g. whether i
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Jul 20, 2017 at 12:16 PM, Sokolov Yura
> wrote:
> > But in fact, vacuum process performs FSYNC! It happens, cause vacuum
> > evicts dirty pages from its ring buffer. And to evict dirty page, it
> > has to be sure WAL record about its
On Thu, Jul 20, 2017 at 12:16 PM, Sokolov Yura
wrote:
> So, from my point of view, no one just evaluate performance of increased
> ring buffer for vacuum.
I think that argument is clearly incorrect. In commit
6382448cf96a9b88d418cbaf86027b63f465b5d8, which you cited, Tom even
added a note in the
On Thu, Jul 20, 2017 at 7:59 AM, Robert Haas wrote:
> >
> > Initially I wanted to make BAS_BULKWRITE and BAS_VACUUM ring sizes
> > configurable, but after testing I don't see much gain from increasing
> > ring buffer above 16MB. So I propose just 1 line change.
>
> I think the question for this p
On Thu, Jul 20, 2017 at 1:08 PM, Claudio Freire wrote:
> So, the 64x increase may be justifiable in absolute terms: it's not
> unlikely that a 16MB buffer will be evicted from the OS cache before
> vacuum is done with it, even in heavily throttled vacuums.
Sorry, that should read "It's not *likel
On 2017-07-20 19:04, Tom Lane wrote:
Claudio Freire writes:
On Thu, Jul 20, 2017 at 11:59 AM, Robert Haas
wrote:
I think the question for this patch is "so, why didn't we do it this
way originally?".
It's no secret that making the ring buffer larger will improve
performance -- in fact, not h
On 2017-07-20 17:59, Robert Haas wrote:
On Tue, Jul 18, 2017 at 6:09 AM, Sokolov Yura
wrote:
I investigated autovacuum performance, and found that it suffers a lot
from small ring buffer. It suffers in a same way bulk writer suffered
before Tom Lane's commit 6382448cf96:
Tom Lane 2009-06-23
On Thu, Jul 20, 2017 at 12:51 PM, Robert Haas wrote:
> On Thu, Jul 20, 2017 at 11:09 AM, Claudio Freire
> wrote:
>>> It's no secret that making the ring buffer larger will improve
>>> performance -- in fact, not having a ring buffer at all would improve
>>> performance even more. But it would a
Claudio Freire writes:
> On Thu, Jul 20, 2017 at 11:59 AM, Robert Haas wrote:
>> I think the question for this patch is "so, why didn't we do it this
>> way originally?".
>>
>> It's no secret that making the ring buffer larger will improve
>> performance -- in fact, not having a ring buffer at a
On Thu, Jul 20, 2017 at 11:09 AM, Claudio Freire wrote:
>> It's no secret that making the ring buffer larger will improve
>> performance -- in fact, not having a ring buffer at all would improve
>> performance even more. But it would also increase the likelihood that
>> the background work of vac
On Thu, Jul 20, 2017 at 11:59 AM, Robert Haas wrote:
> On Tue, Jul 18, 2017 at 6:09 AM, Sokolov Yura
> wrote:
>> I investigated autovacuum performance, and found that it suffers a lot
>> from small ring buffer. It suffers in a same way bulk writer suffered
>> before Tom Lane's commit 6382448cf96:
On Tue, Jul 18, 2017 at 6:09 AM, Sokolov Yura
wrote:
> I investigated autovacuum performance, and found that it suffers a lot
> from small ring buffer. It suffers in a same way bulk writer suffered
> before Tom Lane's commit 6382448cf96:
>
>> Tom Lane 2009-06-23 00:04:28
>> For bulk write operat
Good day, every one.
I investigated autovacuum performance, and found that it suffers a lot
from small ring buffer. It suffers in a same way bulk writer suffered
before Tom Lane's commit 6382448cf96:
Tom Lane 2009-06-23 00:04:28
For bulk write operations (eg COPY IN), use a ring buffer of 16M
39 matches
Mail list logo
