From: MichaelDBA <MichaelDBA@sqlexec.com>
To: Thomas Markus <t.markus@proventis.net>
Cc: pgsql-admin@postgresql.org
Subject: Re: Autovacuum after bulk data insert(millions!)
Date: Tue, 17 Oct 2017 08:24:01 -0400
Message-ID: <59E5F661.3060600@sqlexec.com> (raw)
In-Reply-To: <f8698162-8ca7-0cf8-8738-d44726223af7@proventis.net>
References: <CAAV2-mXmqCYn3Q56rpk65cXABFv8TqX7fVPoN_BQhNnynL38YQ@mail.gmail.com>
<CAPfkCSAtzO1oLnAC8zGN7vTGDNe6sgEpQLtj6npbDqGSa-8gfQ@mail.gmail.com>
<CAAV2-mX6k2G-v95b-0tK5BjF14TkQ2mGBpdx5FAgTxKkhsGAvQ@mail.gmail.com>
<f8698162-8ca7-0cf8-8738-d44726223af7@proventis.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
Another thing to consider here is whether there are queries running
against these tables shortly after the bulk inserts are done. Visibility
checks can become expensive if these recent tuple inserts are not
vacuumed right away.
Please give more context to the SQL workload for a normal day. Are
there multiple bulk inserts? How often? Any significant window where
they occur? How many queries and how often related to these bulked up
tables?
Also, you may end up choosing a strategy that involves making autovacuum
toggle between being more or less aggressive based upon knowledge of the
SQL workload.
Regards,
Michael Vitale
> Thomas Markus <mailto:t.markus@proventis.net>
> Tuesday, October 17, 2017 7:48 AM
> Hi,
>
> Am 17.10.17 um 13:37 schrieb Günce Kaya:
> works same for a database, so it depends on your usecase
>
> * disable autovacuum for instance
> * run 'vacuumdb -a -z' manually/in cron
>
> Regards
> Thomas
>
> Günce Kaya <mailto:guncekaya14@gmail.com>
> Tuesday, October 17, 2017 7:37 AM
> Hello Fabrízio,
>
> Thank you for your advice but I'm not asking for only a specific table
> and not looking for temporary solution. Previous post may not clear to
> much and I'd explain again.
>
> So autovacuum process takes long time for that database. I don't know
> how can I estimate timing for a vacuum after insert millions of bulk
> data to a table. So there are many table inserting bulk data daily.
> This solution not for only a table. I'm looking a solution for a
> database. Data volume of this database is around 2GB so many
> transactions in a day.
>
> This is only suggestion and I'm really curious because can not
> estimate what do you think about that, what if disable autovacuum and
> vacuum all tables in every month?
>
> Regards,
> Gunce
>
>
>
>
> --
> Gunce Kaya
>
> Linkedin <https://tr.linkedin.com/in/guncekaya; - Twitter
> <https://twitter.com/gguncesi; - Blog
> <http://www.guncekaya.blogspot.com.tr/;
> Fabrízio de Royes Mello <mailto:fabrizio@timbira.com.br>
> Tuesday, October 17, 2017 7:16 AM
>
>
> 2017-10-17 4:59 GMT-02:00 Günce Kaya <guncekaya14@gmail.com
> <mailto:guncekaya14@gmail.com>>:
> >
> > Hi all,
> >
> > We have a database that is used for CRM. During day there are many
> process like bulk loading large amounts of data(not thousand like
> millions!). And all day we observe auto vacuum in server status. It
> takes long time. I'm curious what happens if we disable autovacuum for
> a database that process bulk insert? After insert data a table, what
> autovacuum will do for that table?
> >
> > I've read some article like; "The autovacuum process takes care of
> several maintenance chores inside your database that you really need.
> Generally, if you think you need to turn regular vacuuming off because
> it's taking too much time or resources, that means you're doing it
> wrong. The answer to almost all vacuuming problems is to vacuum more
> often, not less, so that each individual vacuum operation has less to
> clean up.
> > However, it's acceptable to disable autovacuum for short periods of
> time, for instance when bulk loading large amounts of data."
> >
> > The reason why I'm asking, millions of data is inserting to CRM
> database all day. What is your advice for that scenario? Should I
> disable autovacuum during bulk process or disable autovacuum totally
> and autovacuum tables in a some period?
> >
>
> One option is:
> 1) Disable autovacuum in target tables
> 2) Run bulk load process
> 3) Run VACUUM ANALYZE manually
> 4) Enable autovacuum in target tables
>
> Regards,
>
> --
> Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
> PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> Günce Kaya <mailto:guncekaya14@gmail.com>
> Tuesday, October 17, 2017 2:59 AM
> Hi all,
>
> We have a database that is used for CRM. During day there are many
> process like bulk loading large amounts of data(not thousand
> like millions!). And all day we observe auto vacuum in server status.
> It takes long time. I'm curious what happens if we disable autovacuum
> for a database that process bulk insert? After insert data a table,
> what autovacuum will do for that table?
>
> I've read some article like; /"The autovacuum process takes care of
> several maintenance chores inside your database that you really need.
> Generally, if you think you need to turn regular vacuuming off because
> it's taking too much time or resources, that means you're doing it
> wrong. The answer to almost all vacuuming problems is to vacuum more
> often, not less, so that each individual vacuum operation has less to
> clean up./
> /However, it's acceptable to disable autovacuum for short periods of
> time, for instance when bulk loading large amounts of data."/
>
> The reason why I'm asking, millions of data is inserting to CRM
> database all day. What is your advice for that scenario? Should I
> disable autovacuum during bulk process or disable autovacuum totally
> and autovacuum tables in a some period?
>
> Regards,
> Gunce Kaya
>
> Linkedin <https://tr.linkedin.com/in/guncekaya; - Twitter
> <https://twitter.com/gguncesi; - Blog
> <http://www.guncekaya.blogspot.com.tr/;
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: MichaelDBA@sqlexec.com, t.markus@proventis.net
Subject: Re: Autovacuum after bulk data insert(millions!)
In-Reply-To: <59E5F661.3060600@sqlexec.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox