Dan Sugalski writes:
> Is there any practical limit to the number of shared buffers PG 8.3.7
> can handle before more becomes counter-productive?
Probably, but I've not heard any definitive measurements showing an
upper limit. The traditional wisdom of limiting it to 1G or so dates
from before
Is there any practical limit to the number of shared buffers PG 8.3.7
can handle before more becomes counter-productive? I remember the
buffer management algorithm used to get unhappy with too many buffers
and past a certain point performance dropped with extra memory
pitched at Postgres.
My
Keshav,
> I have one table my_test table . with on index created on one column .
>
>
> I have turned off the sequential scans .
>
> Now when ever i do refresh on this table or press F5 , It increase the
> sequential scans count and
> Sequential tuple read count .
What's a "refresh"?
You can'
Dave Dutcher wrote:
You need a COMMIT for every BEGIN. If you just run a SELECT statement
without first beginning a transaction, then you should not end up with a
connection that is Idle in Transaction. If you are beginning a transaction,
doing a select, and then not committing, then yes that i
Dave Dutcher wrote:
>> From: Shiva Raman
>> Subject: Re: [PERFORM] High CPU load on Postgres Server during Peak
>>
> not explicitly committed.
>
>> We have started updating the code on this.
>>
>
> You need a COMMIT for every BEGIN. If you just run a SELECT statement
> without first
Hi ,
I have one table my_test table . with on index created on one column .
I have turned off the sequential scans .
Now when ever i do refresh on this table or press F5 , It increase the
sequential scans count and
Sequential tuple read count .
Pls help me to understand what exactly is happen
>From: Shiva Raman
>Subject: Re: [PERFORM] High CPU load on Postgres Server during Peak
times
>
>Andy Colson Wrote : ,
>>Eww. I think that's bad. A connection that has a transaction open will
cause lots of row versions,
>>which use up ram, and make it slower to step through the table (even
Bill Kirtley writes:
> select xmin,* from pg_index where indexrelid =
> 'index_users_on_email'::regclass;
> xmin | indexrelid | indrelid | indnatts | indisunique |
> indisprimary | indisclustered | indisvalid | indcheckxmin | indisready
> | indkey | indclass | indoption | indexprs | in
Andy Colson wrote:
> Shiva Raman wrote:
>> Hi
>>
>> Today the load observed very high load . I am pasting the top.
>>
>> _*TOP *_
>> top - 12:45:23 up 79 days, 14:42, 1 user, load average: 45.84,
>> 33.13, 25.84
>> Tasks: 394 total, 48 running, 346 sleeping, 0 stopped, 0 zombie
>> Cpu(s): 49
Bill Kirtley writes:
> For what it's worth:
> select xmin,* from pg_index where indexrelid =
> 'users_key_index'::regclass;
> xmin | indexrelid | indrelid | indnatts | indisunique | indisprimary
> | indisclustered | indisvalid | indcheckxmin | indisready | indkey |
> indclass | indoption
Shiva Raman wrote:
Hi
Today the load observed very high load . I am pasting the top.
_*TOP *_
top - 12:45:23 up 79 days, 14:42, 1 user, load average: 45.84, 33.13,
25.84
Tasks: 394 total, 48 running, 346 sleeping, 0 stopped, 0 zombie
Cpu(s): 49.2%us, 0.8%sy, 0.0%ni, 0.0%id, 0.0%wa,
For 'idle in transaction' issues, you have to fix your code. I faced this
issue couple of months back. How good is your exception handling? Are you
rollingback/comitting your transactions while exceptions are thrown, during
the course of db operations?
Honestly I wouldn't go for these scripts w
Hi
Today the load observed very high load . I am pasting the top.
*TOP *
top - 12:45:23 up 79 days, 14:42, 1 user, load average: 45.84, 33.13,
25.84
Tasks: 394 total, 48 running, 346 sleeping, 0 stopped, 0 zombie
Cpu(s): 49.2%us, 0.8%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.1%si,
50.0%s
On Wed, Sep 23, 2009 at 10:35 PM, Tom Lane wrote:
>
> One thing that is hobbling the performane on 8.4 is that you have
> work_mem set to only 1MB
>
> Other things you might try include increasing join_collapse_limit
> to 12 or so, and reducing random_page_cost.
>
> Another thing to look into is w
> On Thu, Sep 24, 2009 at 9:27 AM, wrote:
>
>> Hi.
>>
>> I have a transaction running at the database for around 20 hours ..
>> still
>> isn't done. But during the last hours it has come to the point where it
>> really hurts performance of "other queries".
>>
>> Given pg_stat_activity output there
> On Thu, Sep 24, 2009 at 2:27 AM, wrote:
>> Hi.
>>
>> I have a transaction running at the database for around 20 hours ..
>> still
>> isn't done. But during the last hours it has come to the point where it
>> really hurts performance of "other queries".
>
> What is your transaction doing during
> Hello postgres wizards,
>
> We recently upgraded from 8.1.5 to 8.4
> We have a query (slow_query.sql) which took about 9s on 8.1.5
> On 8.4, the same query takes 17.7 minutes.
>
> The code which generated this query is written to support the
> calculation of arbitrary arithmetic expressions acros
Euler Taveira de Oliveira-2 wrote:
>
> solAris23 escreveu:
>> I am trying to index a field in my database of size about 16K rows, but i
>> m
>> getting this error.
>>
> Why are you want to index such a big field? BTW, it'll be worthless.
>
>> " Index row requires 9324 bytes maximum size is 81
On Thu, Sep 24, 2009 at 2:27 AM, wrote:
> Hi.
>
> I have a transaction running at the database for around 20 hours .. still
> isn't done. But during the last hours it has come to the point where it
> really hurts performance of "other queries".
What is your transaction doing during this time?
>
On Thu, Sep 24, 2009 at 9:27 AM, wrote:
> Hi.
>
> I have a transaction running at the database for around 20 hours .. still
> isn't done. But during the last hours it has come to the point where it
> really hurts performance of "other queries".
>
> Given pg_stat_activity output there seems to be
> I have a transaction running at the database for around 20 hours .. still
> isn't done. But during the last hours it has come to the point where it
> really hurts performance of "other queries".
>
> Given pg_stat_activity output there seems to be no locks interfering but
> the overall cpu-usage o
Hi.
I have a transaction running at the database for around 20 hours .. still
isn't done. But during the last hours it has come to the point where it
really hurts performance of "other queries".
Given pg_stat_activity output there seems to be no locks interfering but
the overall cpu-usage of all
22 matches
Mail list logo
