In response to "Albe Laurenz" <laurenz.albe@xxxxxxxxxx>:
> Laurent Raufaste wrote:
> > The problem was that the optimiser didn't know how to run the queries
> > well and used millions of tuples for simple queries. For each tuple
> > used it was updating some bit in the table file, resulting in a huge
> > writing activity to that file.
>
> Good that you solved your problem.
>
> PostgreSQL doesn't write into the table files when it SELECTs data.
>
> Without an EXPLAIN plan it is impossible to say what PostgreSQL
> was doing, but most likely it was building a large hash structure
> or something similar and had to dump data into temporary files.
As a parting comment on this topic ...
Based on his previous messages, he was able to definitively tie
filesystem write activity to specific tables, but also claimed that
his PG logs showed only SELECT statements being executed.
However, the part I wanted to comment on (and got busy yesterday so
am only getting to it now) is that there's no guarantee that SELECT
isn't modifying rows.
SELECT nextval('some_seq');
is the simplest example I can imagine of a select that modifies database
data, but it's hardly the only one. I suspect that the OP has procedures
in his SELECTs that are modifying table data, or triggers that do it ON
SELECT or something similar.
Of course, without any details, this is purely speculation.
--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/
wmoran@xxxxxxxxxxxxxxxxxxxxxxx
Phone: 412-422-3463x4023
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
