Hi Greg,
I've got 32M shared on a 1G machine and 16 checkpoint segments.
I'll run some tests against 64 segments and see what happens.
Your previous postings were extremely helpful wrt the MVCC issue.
I thank you!
-john
Greg Smith wrote:
On Fri, 26 Sep 2008, John Huttley wrote:
running
Hi Andrew,
There are two problems.
The first is the that if there is a table with a index and an update is
performed on a non indexed field,
the index is still re indexed. this is part of the trade-offs of MVCC.
Apparently this is documented under 'MVCC' in the manual. It should be
documented u
It would be useful to confirm that this is a backend process.
With top, hit the 'c' key to show the full path / description of the
process.
Backend postgres processes should then have more useful descriptions of what
they are doing and identifying themselves.
You can also confirm what query is caus
Hi,
On Fri, Sep 26, 2008 at 07:24:55AM +1200, John Huttley wrote:
> I've just had an interesting encounter with the slow full table update
> problem that is inherent with MVCC
Quite apart from the other excellent observations in this thread, what
makes you think this is an MVCC issue exactly?
A
kiki wrote:
> The number of rows returned by the query varies, right now is:
>
> 49 row(s)
> Total runtime: 3,965.718 ms
> The table currently has 971582 rows.
>
> But the problem is that when database server is restarted everything works
> fine and fast. No heavy loads of the processor and as time
Thank's for your response.
The situation is that the top result is when the server is already
exhibiting problems.
The number of rows returned by the query varies, right now is:
49 row(s)
Total runtime: 3,965.718 ms
The table currently has 971582 rows.
But the problem is that when database serv
