Scott Marlowe wrote:
Also note that the argument that autovacuum chews up too much IO is
moot now that you can set cost delay to 10 to 20 milliseconds. Unless
you're running on the hairy edge of maximum IO at all times, autovac
should be pretty much unnoticed
And if you're running on the hairy e
Robert Haas írta:
2009/11/9 Laszlo Nagy :
We have a bigger table with some million rows. Number of index scans is
high, number of seq reads is low. This table if often joined with
others... so we want to buy a new SSD drive, create a tablespace on it
and put this big table on it. Random read
On Mon, Nov 9, 2009 at 9:46 AM, Anj Adu wrote:
> Why is reindex needed ?
VACUUM FULL does not fix index bloat, only table boat.
...Robert
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Mon, Nov 9, 2009 at 5:22 AM, Robert Haas wrote:
> On Sat, Nov 7, 2009 at 11:58 PM, Aris Samad-Yahaya
> wrote:
>> We vacuum analyze nightly, and vacuum normally ad-hoc (but we're going to
>> schedule this weekly moving forward).
>>
>> Interesting pointer about system catalog bloat. I tried to v
Why is reindex needed ?Unless most of the key values get deleted
frequently..this is not needed. (I am assuming postgres 8.x and above)
On Sun, Nov 8, 2009 at 7:58 PM, Robert Haas wrote:
> On Sat, Nov 7, 2009 at 11:58 PM, Aris Samad-Yahaya
> wrote:
>> We vacuum analyze nightly, and vacuum no
Brian Karlak writes:
> I have a simple queuing application written on top of postgres which I'm
> trying to squeeze some more performance out of.
Have you tried to write a custom PGQ consumer yet?
http://wiki.postgresql.org/wiki/PGQ_Tutorial
Regards,
--
dim
--
Sent via pgsql-performance mai
2009/11/9 Laszlo Nagy :
> We have a bigger table with some million rows. Number of index scans is
> high, number of seq reads is low. This table if often joined with
> others... so we want to buy a new SSD drive, create a tablespace on it
> and put this big table on it. Random read speed on SSD is
Hi All,
We have a bigger table with some million rows. Number of index scans is
high, number of seq reads is low. This table if often joined with
others... so we want to buy a new SSD drive, create a tablespace on it
and put this big table on it. Random read speed on SSD is identical to
seq rea
On Sat, Nov 7, 2009 at 11:58 PM, Aris Samad-Yahaya
wrote:
> We vacuum analyze nightly, and vacuum normally ad-hoc (but we're going to
> schedule this weekly moving forward).
>
> Interesting pointer about system catalog bloat. I tried to vacuum full the
> system catalog tables (pg_*), and the perfo
On Mon, Nov 9, 2009 at 3:58 AM, Robert Haas wrote:
>
>
> And maybe REINDEX, too.
yup, nevermind the mess in table, indices are getting fscked much quicker
than table it self, because of its structure.
--
GJ
10 matches
Mail list logo
