Thanks for reply, Tom.
> It's hard to evaluate that without knowing what the actual table/index
> sizes are, or IOW what is the reported bloat on a percentage basis?
The table size is reported as: 4036 MB according to:
select pg_size_pretty(pg_table_size('table_name'));
Compared to 1669 MB
I recently set up partitioning on a table that sees heavy insert
traffic. There are never updates or deletes, we just drop the partitions
later.
It's my understanding that bloat can only appear through updates or
deletes, but these partitions are reported to have significant bloat in
them. Where
On 05/04/2011 12:54 PM, Scott Marlowe wrote:
> On Wed, May 4, 2011 at 10:48 AM, Mark Stosberg wrote:
>>
>>>> 5. Finally, I'll drop the indexes on the parent table and
>>>> truncate it.
>>
>> Luckily I noticed the problem with TRUNCATE an
>> 5. Finally, I'll drop the indexes on the parent table and
>> truncate it.
Luckily I noticed the problem with TRUNCATE and partitioning before my
work got to production.
TRUNCATE cascades automatically and silently to child tables, which was
not my intent.
This is mentioned here:
http://wiki.
On 04/27/2011 10:48 AM, Mark Stosberg wrote:
>
> Hello,
>
> I'm working on moving a table with over 30 million to rows to be
> partitioned. The table seeing several inserts per second. It's
> essentially an activity log that only sees insert activity and is
> l
> Similar posting on partition table, take this inputs before going
> forward with partition table.
>
> http://archives.postgresql.org/pgsql-general/2011-04/msg00808.php
>
> Best solution given by Greg Smith as well Vick.
Thanks for the replies.
Today I reviewed the section on partitioning fro
Hello,
I'm working on moving a table with over 30 million to rows to be
partitioned. The table seeing several inserts per second. It's
essentially an activity log that only sees insert activity and is
lightly used for reporting, such that queries against it can safely be
disabled during a transit
own plugin to check that no more than 10 of the last
100 searches took more than 10 seconds to execute. If that is ever true, we
definitely have a situation we want to look into.
What luck have others of you had with devising a way to monitor if your
PostgreSQL server is "slow" ?
