On Mon, Nov 9, 2009 at 3:58 AM, Robert Haas robertmh...@gmail.com 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
On Sat, Nov 7, 2009 at 11:58 PM, Aris Samad-Yahaya
a...@quickschools.com 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
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
2009/11/9 Laszlo Nagy gand...@shopzeus.com:
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
Brian Karlak zen...@metaweb.com 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
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 robertmh...@gmail.com wrote:
On Sat, Nov 7, 2009 at 11:58 PM, Aris Samad-Yahaya
a...@quickschools.com wrote:
On Mon, Nov 9, 2009 at 5:22 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Nov 7, 2009 at 11:58 PM, Aris Samad-Yahaya
a...@quickschools.com wrote:
We vacuum analyze nightly, and vacuum normally ad-hoc (but we're going to
schedule this weekly moving forward).
Interesting pointer about
On Mon, Nov 9, 2009 at 9:46 AM, Anj Adu fotogra...@gmail.com 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:
Robert Haas írta:
2009/11/9 Laszlo Nagy gand...@shopzeus.com:
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
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
10 matches
Mail list logo
