In response to "Laurent Raufaste" <[EMAIL PROTECTED]>:
> 2008/3/21, Gregory Stark <[EMAIL PROTECTED]>:
> >
> > Well that's true it does. But only once per row. So analyze would have set
> > the
> > bit on every row. You could do the same thing with something ligter like
> > "select count(*) fro
2008/3/21, Gregory Stark <[EMAIL PROTECTED]>:
>
> Well that's true it does. But only once per row. So analyze would have set the
> bit on every row. You could do the same thing with something ligter like
> "select count(*) from ".
Well, the table has been analyzed, I did SELECT, PG write on the
"Laurent Raufaste" <[EMAIL PROTECTED]> writes:
> All this make me think that PG was setting some bit on every row it
> used, which caused this massive write activity (3MB/s) in the table
> files. I'm talking about approx. 50 SELECT per second for a single
> server.
Well that's true it does. But o
2008/3/20, Tom Lane <[EMAIL PROTECTED]>:
>
> Another way that SELECT can cause disk writes is if it sets hint bits on
> recently-committed rows. However, if the tables aren't actively being
> modified any more, you'd expect that sort of activity to settle out pretty
> quickly.
>
> I concur wit
On Thu, 20 Mar 2008, Albe Laurenz wrote:
PostgreSQL doesn't write into the table files when it SELECTs data.
It could easily be hint bit updates that are set by selects getting
written.
Kris Jurka
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make cha
Bill Moran <[EMAIL PROTECTED]> writes:
> 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.
Another way that SELECT can cause disk writes is if it sets hint bits on
recently-committed row
In response to "Albe Laurenz" <[EMAIL PROTECTED]>:
> 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
>
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 pr
2008/3/19, Laurent Raufaste <[EMAIL PROTECTED]>:
> What does it writes so much in the base directory ? If it's some
> temporary table or anything, how can I locate it so I can fix the
> problem ?
Thanks for your help everybody ! I fixed the problem by doing an
ANALYZE to every table (yes I'm so
Laurent Raufaste wrote:
> I have a big PG server dedicated to serve only SELECT queries.
> The database is updated permanently using Slony.
>
> [...] load is huge.
>
> In order to locate the problem, I stopped Slony (no updates anymore),
> mounted the database and index partitions with the sync o
On Wed, 19 Mar 2008, Laurent Raufaste wrote:
When I try to plug it to a client (sending 20 transactions/s) it works
fine for like 10 minutes, then start to write a lot in the pgdata/base
directory (where the database files are, not the index). It writes so
much (3MB/s randomly) that it can't
In response to "Laurent Raufaste" <[EMAIL PROTECTED]>:
> I have a big PG server dedicated to serve only SELECT queries.
> The database is updated permanently using Slony.
>
> The server has 8 Xeon cores running at 3Ghz, 24GB of RAM and the
> following disk arrays:
> - one RAID1 serving the OS and
I have a big PG server dedicated to serve only SELECT queries.
The database is updated permanently using Slony.
The server has 8 Xeon cores running at 3Ghz, 24GB or RAM and the
following disk arrays:
- one RAID1 serving the OS and the pg_xlog
- one RAID5 serving the database and the tables (base d
13 matches
Mail list logo
