From: | Kenneth Marshall <ktm(at)rice(dot)edu> |
---|---|
To: | Nicolas Grilly <nicolas(at)gardentechno(dot)com> |
Cc: | Vick Khera <vivek(at)khera(dot)org>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Clustered index to preserve data locality in a multitenant application? |
Date: | 2016-08-31 16:22:15 |
Message-ID: | 20160831162215.GG4950@aart.rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Aug 31, 2016 at 06:06:54PM +0200, Nicolas Grilly wrote:
> On Wed, Aug 31, 2016 at 6:05 PM, Kenneth Marshall <ktm(at)rice(dot)edu> wrote:
>
> > We just run it via cron. In our case, we run it once a day, but depending
> > on
> > your churn, it could be run once a week or more.
> >
>
> Could you provide some numbers: what is the size of the tables or tables
> that are repacked? how long does it take? is there a performance impact
> during the repack?
Hi,
The key is that there must be enough I/O capacity to handle your routine
DB access needs plus the additional usage by the repack operation. Running
the repack during a slow period does not tangibly impact DB performance and
completes in a reasonable period of time. Your best best would be to set
up a test environment. By way of example, running our repack during peak
usage can take over 5 hours and less than 30m outside of peak when there
is excess I/O capacity. You should be able to use your I/O monitoring
system to get an idea about your I/O headroom.
Regards,
Ken
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolas Grilly | 2016-08-31 21:55:47 | Re: Clustered index to preserve data locality in a multitenant application? |
Previous Message | Nicolas Grilly | 2016-08-31 16:06:54 | Re: Clustered index to preserve data locality in a multitenant application? |