SELECT relpages, reltuples FROM pg_class WHERE relname ='users';
relpages | reltuples
--+---
54063 | 2307
(1 row)
This is a horribly bloated table.
The Output of query on the old server which is fast
relpages | reltuples
--+---
42 |
AIL PROTECTED]> wrote:
> From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Subject: Re: [PERFORM] Postgresql is very slow
> To: [EMAIL PROTECTED]
> Cc: pgsql-performance@postgresql.org
> Date: Tuesday, 24 June, 2008, 3:32 PM
> >> Not necessarily, the 'cost' de
>> Not necessarily, the 'cost' depends on
>> seq_page_cost and there might be
>> other value than 1 (which is the default). A better
>> approach is
>>
>> SELECT relpages, reltuples FROM pg_class WHERE relname =
>> 'users';
>>
>> which reads the values from system catalogue.
>>
> The Output of query
2008/6/24 Scott Marlowe <[EMAIL PROTECTED]>:
> On Mon, Jun 23, 2008 at 11:48 PM, bijayant kumar <[EMAIL PROTECTED]> wrote:
(...)
>> The output of EXPLAIN query;
>>
>> select * from USERS where email like '%bijayant.kumar%';
>> This simplest query tooks 10 minutes and server loads goes from 0.35 to
--- On Tue, 24/6/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Subject: Re: [PERFORM] Postgresql is very slow
> To: "Scott Marlowe" <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], pgsql-pe
>> I was not aware of the VACUUM functionality earlier, but some times back
>> i read and run this on the server but i did not achieve anything in
>> terms of performance. The server is running from 1 to 1.5 years and we
>> have done VACUUM only once.
>
> vacuuming isn't so much about performance a
> Definitely need a vacuum full on this table, likely followed by a reindex.
Or a cluster on the table...
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Mon, Jun 23, 2008 at 11:48 PM, bijayant kumar <[EMAIL PROTECTED]> wrote:
OK, you don't have a ton of updates each day, but they add up over time.
> I was not aware of the VACUUM functionality earlier, but some times back i
> read and run this on the server but i did not achieve anything in te
Hi,
Thanks for the reply. Many gentlemans have replied to my question, thanks to
all of them. I have tried to answer all questions in one mail.
--- On Mon, 23/6/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Subject: Re: [PERF
> System Specification:
> OS :- CentOs 5
> Postgresql 8.1.8
> RAM :- 1 GB
> SWAP 2 GB
[Greg says]
How much memory is actually free, can you include the output from the command
"free" in your reply? What else runs on this server? What is the system load
before and during your query?
While it'
Hi,
> Hello to list,
>
> We have a CentOS-5 server with postgresql-8.1.8 installed. I am struggling
> with postgresql performance. Any query say select * from tablename takes
> 10-15 mins to give the output, and while executing the query system loads
> goes up like anything. After the query output
bijayant kumar wrote:
select * from tablename takes 10-15 mins to give the output
There are better ways to dump data than using a database; that's
not a useful query.
Any query select,insert,update simple or complex behaves in the same way
Have you set up suitable indexes for your operat
On Monday 23 June 2008 07:06:54 bijayant kumar wrote:
> Hello to list,
>
> We have a CentOS-5 server with postgresql-8.1.8 installed. I am struggling
> with postgresql performance. Any query say select * from tablename takes
> 10-15 mins to give the output, and while executing the query system load
Hello to list,
We have a CentOS-5 server with postgresql-8.1.8 installed. I am struggling with
postgresql performance. Any query say select * from tablename takes 10-15 mins
to give the output, and while executing the query system loads goes up like
anything. After the query output, system load
14 matches
Mail list logo
