Re: vacuum of empty table slows down as database table count grows

From: marcin kowalski <yoshi314(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Jerry Sievers <gsievers19(at)comcast(dot)net>, "pgsql-general(at)postgresql(dot)org >> PG-General Mailing List" <pgsql-general(at)postgresql(dot)org>
Subject: Re: vacuum of empty table slows down as database table count grows
Date: 2017-01-05 07:18:17
Message-ID: CABKsJ=RSWjx0+4wK+nbA-rnohPt3708CPjaRG8d_av89eEcy=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks, i'll redo the benchmarks and report back how things look now.

2017-01-04 20:33 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>>> >
>>> > This is irrelevant of amount of data restored, i am seeing the same
>>> behavior with just schema restore, as well as with schema+data restores.
>>> >
>>> > If anyone is interested i may upload the schema data + my benchmarking
>>> script with collected whisper data from my test run (i've been plotting it
>>> in grafana via carbon)
>>> >
>>> > Is this a known issue? Can i do anything to improve performance here?
>>>
>>
>> we had 10K and more tables in one database - and we had lot of issues.
>>
>> I know so Tomas fixed some issues, but we need the stat files in tmpfs
>>
>> please, read this article https://blog.pgaddict.com/pos
>> ts/the-two-kinds-of-stats-in-postgresql
>>
>
> http://hacksoclock.blogspot.cz/2014/04/putting-
> statstempdirectory-on-ramdisk.html
>
>
>>
>> Regards
>>
>> Pavel
>>
>> >
>>>
>>> --
>>> Jerry Sievers
>>> Postgres DBA/Development Consulting
>>> e: postgres(dot)consulting(at)comcast(dot)net
>>> p: 312.241.7800
>>>
>>>
>>> --
>>> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-general
>>>
>>
>>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message vod vos 2017-01-05 12:44:06 Re: COPY: row is too big
Previous Message Vitaly Burovoy 2017-01-05 05:19:01 Re: The best way to deal with hierarchical data (was: Postgresql query HAVING do not work)