I have some tables which have an extremely high amount of update
activity on them. I have changed autovacuum parameters (cost delay and
limit), and whereas before they would never be vacuumed and bloat they
are running fine.
However, as the platform scales, I am afraid I will reach the same
situa
On Wed, Jan 13, 2010 at 5:51 PM, Benjamin Krajmalnik wrote:
> I have some tables which have an extremely high amount of update activity on
> them. I have changed autovacuum parameters (cost delay and limit), and
> whereas before they would never be vacuumed and bloat they are running fine.
>
> Ho
You are always very helpful.
> -Original Message-
> From: Scott Marlowe [mailto:scott.marl...@gmail.com]
> Sent: Wednesday, January 13, 2010 5:58 PM
> To: Benjamin Krajmalnik
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Question on moving data to new partit
On Wed, Jan 13, 2010 at 6:11 PM, Benjamin Krajmalnik wrote:
> Yes, I will be using table inheritance and inheriting the current table where
> the data resides.
> I was wondering if it would be "kosher" to perform the insert on itself, but
> I guess since the rules engine takes over there should
Scott Marlowe wrote:
On Wed, Jan 13, 2010 at 6:11 PM, Benjamin Krajmalnik wrote:
Yes, I will be using table inheritance and inheriting the current table where
the data resides.
I was wondering if it would be "kosher" to perform the insert on itself, but I
guess since the rules engine tak
On Wed, Jan 13, 2010 at 7:30 PM, Radhika Sambamurti wrote:
>
> Hi,
> I am currently looking into partitioning a table of which 90% of the lookups
> are for the prior week. It has about 9 million rows and selects are a bit
> slow, since the table is joined to two other tables. I am planning on
"Benjamin Krajmalnik" writes:
> As a result, I have decided to partition the table and add to each record a
> partition id, which can be used to route it to the correct partition.
>
> Presently, all of the records reside on what will ultimately become the
> parent partition.
>
> What would be th
