The table, VOTER, contains 3,090,013 rows and each row is about 120 bytes
wide. It's loaded via a batch process in one shot, and the load is
followed by an VACUUM FULL ANALYZE. Its structure is shown at the bottom
of the message.
if the table wasn't empty before and has indices defined, try
is there a possibility for creating views or temp tables in memory to
avoid disk io when user makes select operations?
you might also want to look into "materialized views":
http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html
http://www.varlena.com/varlena/GeneralBits/64.php
another approach would be:
table product:
productid int8 PK
productname charvar(255)
table versions
productid int8 FK
versionid int8 PK
size
color
...
quantity int4
an example would be then:
table product:
- productid: 123, productname: 'nice cotton t-shirt'
- productid: 442, productname:
Sure... I've never been asked to consult on our stuff, and in any case,
I don't do web front-ends (one of the nice things about working with a
team of other consultants). AFAIK IIS will happily talk to PostgreSQL
(though maybe I'm wrong there...)
iis (yeah, asp in a successfull productive enviro
Try a), b), and c) in order on the "offending" tables as they address
the problem at increasing cost...
thanks alot for the detailed information! the entire concept of vacuum isn't
yet that clear to me, so your explanations and hints are very much
appreciated. i'll defeni
in our db system (for a website), i notice performance boosts after a
vacuum
full. but then, a VACUUM FULL takes 50min+ during which the db is not
really
accessible to web-users. is there another way to perform maintenance
tasks
AND leaving the db fully operable and accessible?
You're not doi
That does sound like a lack-of-vacuuming problem. If the performance
goes back where it was after VACUUM FULL, then you can be pretty sure
of it. Note that autovacuum is not designed to fix this for you: it
only ever issues regular vacuum not vacuum full.
in our db system (for a website), i no
hi mike
In particular I'm interested in a view which materializes whenever
queried, and is invalidated as soon as underlying data is changed.
from the german pgsql list earlier last week:
http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html
this seems to be pretty much what
we experienced the same. had 2 win2003 servers - www and db connected to the
same router through 100mbit. the performance was quite bad. now we run the
db on the same machine as the web and everything runs smooth.
cheers,
thomas
- Original Message -
From: "Josep Maria Pinyol Fontseca
hi michael
Have you ANALYZEd your database? VACUUMing?
Of course ... before 8.1 we routinely did a vacuum full analyze each
night. As of 8.1 we use autovacuum.
what i noticed is autovacuum not working properly as it should. i had 8.1
running with autovacuum for just 2 days or so and got w
10 matches
Mail list logo
