OK I found the cause, it was a default settings added on server start.
(-B 1024) Gr!
Now it works really better I devide the full time per 2.
I suppose I steal have to look deep in the procedure to see some hack,
has somebody suggest, I will try to buffer all updates in one.
One
We have very good experiences with openVZ as virtualizer.
Since it's not a para virtualization like xen it's very fast. Almost
as fast as the host.
www.openvz.org
Am 04.03.2008 um 16:43 schrieb Theo Kramer:
Hi
We are thinking of running a PostgreSQL instance on a virtual host
under
Dear Friends,
I have a table with 50 lakhs records, the table has more then 10
fields, i have primary key, i have select query with count(*) without any
condition, it takes 17 seconds.
I have another one query which will do joins with other small tables, it
takes 47 seconds to give
DGB87PGD
--
With Best Regards,
Petchimuthulingam S
Hi,
Le mercredi 05 mars 2008 à 11:39 +0100, Steinar H. Gunderson a écrit :
Without knowing what a lakhs record is,
I had the same question... and Wikipedia gave me the answer : it is an
Indian word meaning 10^5, often used in indian english.
Franck
--
Sent via pgsql-performance mailing
On Wed, Mar 05, 2008 at 02:27:08AM -0800, SPMLINGAM wrote:
I have a table with 50 lakhs records, the table has more then 10
fields, i have primary key, i have select query with count(*) without any
condition, it takes 17 seconds.
Without knowing what a lakhs record is, it's pretty obvious
Without knowing what a lakhs record is,
I had the same question... and Wikipedia gave me the answer : it is an
Indian word meaning 10^5, often used in indian english.
Thank you (both OP and this post) for enlightening us with this word.
--
regards
Claus
When lenity and cruelty play for
Hi,
I've run it on xen. works OK. Course this is all predicated upon your
expectations. If you expect it to be as fast as a dedicated machine,
you will be dissapointed.
Dave
On 5-Mar-08, at 3:54 AM, Moritz Onken wrote:
We have very good experiences with openVZ as virtualizer.
Since it's
Hello,
We had a bad experience with PostgreSQL running in OpenVZ (year and a
half year ago): OpenVZ kernel killed postmaster with strange signals
from time to time, failcounters of OpenVZ did not worked as expected
in this moments, PostgreSQL fighted for the disk with applications in
other
In response to Ivan Zolotukhin [EMAIL PROTECTED]:
We had a bad experience with PostgreSQL running in OpenVZ (year and a
half year ago): OpenVZ kernel killed postmaster with strange signals
from time to time, failcounters of OpenVZ did not worked as expected
in this moments, PostgreSQL
Hello,
On Wed, Mar 5, 2008 at 5:40 PM, Bill Moran
[EMAIL PROTECTED] wrote:
In response to Ivan Zolotukhin [EMAIL PROTECTED]:
We had a bad experience with PostgreSQL running in OpenVZ (year and a
half year ago): OpenVZ kernel killed postmaster with strange signals
from time to time,
-Original Message-
From: SPMLINGAM
Subject: [PERFORM] postgresql performance
Dear Friends,
I have a table with 50 lakhs records, the table has more
then 10 fields, i have primary key, i have select query with
count(*) without any condition, it takes 17 seconds.
17 seconds
On Wed, Mar 5, 2008 at 4:39 AM, in message [EMAIL PROTECTED],
Steinar H. Gunderson [EMAIL PROTECTED] wrote:
it's pretty obvious that you
haven't vacuumed in a very long time. Run VACUUM FULL on your tables
If you use VACUUM FULL, you should probably throw in ANALYZE with
it, and REINDEX,
In response to Dave Dutcher [EMAIL PROTECTED]:
-Original Message-
From: SPMLINGAM
Subject: [PERFORM] postgresql performance
Dear Friends,
I have a table with 50 lakhs records, the table has more
then 10 fields, i have primary key, i have select query with
count(*)
Below I have two almost identical queries. Strangely enough the one
that uses the index is slower ???
explain analyze select uid from user_profile where
lower(firstname)='angie' and extract(year from age('2008-02-26
02:50:31.382', dob)) = 18 and extract(year from age('2008-02-26
OI6PQO5P
--
With Best Regards,
Petchimuthulingam S
R9PKE431
--
With Best Regards,
Petchimuthulingam S
HZ5DHKQJ
--
With Best Regards,
Petchimuthulingam S
C5BK4513
--
With Best Regards,
Petchimuthulingam S
petchimuthu lingam wrote:
C5BK4513
Ahh - you are sending this to the wrong address, these are not being
sent by the postgres mailing list.
Check which address you are replying to next time...
--
Postgresql php tutorials
http://www.designmagick.com/
--
Sent via pgsql-performance mailing
sathiya psql wrote:
count(*) tooks much time...
but with the where clause we can make this to use indexing,... what
where clause we can use??
Am using postgres 7.4 in Debian OS with 1 GB RAM,
am having a table with nearly 50 lakh records,
Looks suspiciously like a question asked
P289ZUDZ
--
With Best Regards,
Petchimuthulingam S
count(*) tooks much time...
but with the where clause we can make this to use indexing,... what where
clause we can use??
Am using postgres 7.4 in Debian OS with 1 GB RAM,
am having a table with nearly 50 lakh records,
it has more than 15 columns, i want to count how many records are there, it
On Thu, Mar 6, 2008 at 5:08 PM, A. Kretschmer
[EMAIL PROTECTED] wrote:
am having a table with nearly 50 lakh records,
it has more than 15 columns, i want to count how many records are there,
it is
taking nearly 17 seconds to do that...
i know that to get a approximate count we can
buy every time i need to put ANALYZE...
this takes the same time as count(*) takes, what is the use ??
On Thu, Mar 6, 2008 at 11:45 AM, Shoaib Mir [EMAIL PROTECTED] wrote:
On Thu, Mar 6, 2008 at 5:08 PM, A. Kretschmer
[EMAIL PROTECTED] wrote:
am having a table with nearly 50 lakh records,
On Thu, Mar 6, 2008 at 5:19 PM, sathiya psql [EMAIL PROTECTED] wrote:
buy every time i need to put ANALYZE...
this takes the same time as count(*) takes, what is the use ??
Dont you have autovacuuming running in the background which is taking care
of the analyze as well?
If not then hmm
There aren't a general solution. If you realy need the exact count of
tuples than you can play with a TRIGGER and increase/decrease the
tuple-count for this table in an extra table.
Of course, this means accepting the cost of obtaining update locks on
the count table.
The
hi,
is there any generalized format for the output for the output of the
explain command ?. If so please send that generalized format to me.
otherwise tell me how to parse the output of explain command to
know where the relation name occurs,where the conditions occurs,
where the join
will you please tell, what is autovacuuming... and wat it ll do... is there
any good article in this
On Thu, Mar 6, 2008 at 11:56 AM, Shoaib Mir [EMAIL PROTECTED] wrote:
On Thu, Mar 6, 2008 at 5:19 PM, sathiya psql [EMAIL PROTECTED]
wrote:
buy every time i need to put ANALYZE...
this
On Thu, Mar 6, 2008 at 5:31 PM, sathiya psql [EMAIL PROTECTED] wrote:
will you please tell, what is autovacuuming... and wat it ll do... is
there any good article in this
Read this --
http://www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html#AUTOVACUUM
--
Shoaib Mir
Fujitsu
is there any way to explicitly force the postgres to use index scan
On Thu, Mar 6, 2008 at 12:06 PM, A. Kretschmer
[EMAIL PROTECTED] wrote:
am Thu, dem 06.03.2008, um 1:26:46 -0500 mailte Mark Mielke folgendes:
There aren't a general solution. If you realy need the exact
count
-- Forwarded message --
From: sathiya psql [EMAIL PROTECTED]
Date: Thu, Mar 6, 2008 at 12:17 PM
Subject: Re: [PERFORM] count * performance issue
To: A. Kretschmer [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
TRIGGER i can use if i want the count of the whole table, but i require for
am Thu, dem 06.03.2008, um 12:13:17 +0530 mailte sathiya psql folgendes:
is there any way to explicitly force the postgres to use index scan
Not realy, PG use a cost-based optimizer and use an INDEX if it make
sense.
On Thu, Mar 6, 2008 at 12:06 PM, A. Kretschmer
[EMAIL PROTECTED] wrote:
am Thu, dem 06.03.2008, um 12:17:55 +0530 mailte sathiya psql folgendes:
TRIGGER i can use if i want the count of the whole table, but i require for
some of the rows with WHERE condition
so how to do that ???
Okay, in this case a TRIGGER are a bad idea. You can use an INDEX on
this row.
am Thu, dem 06.03.2008, um 1:26:46 -0500 mailte Mark Mielke folgendes:
There aren't a general solution. If you realy need the exact count of
tuples than you can play with a TRIGGER and increase/decrease the
tuple-count for this table in an extra table.
Of
QUERY PLAN
--
Aggregate (cost=205756.95..205756.95 rows=1 width=0) (actual time=
114675.042..114675.042 rows=1
On Thu, 6 Mar 2008 12:32:01 +0530
sathiya psql [EMAIL PROTECTED] wrote:
i had a table with 50 lakh record...
it has a column called oid ( obviously all the tables will have
this ), but while doing any operation it is getting slow because of
the number of records...
Actually it isn't
am Thu, dem 06.03.2008, um 12:36:48 +0530 mailte sathiya psql folgendes:
QUERY PLAN
--
Aggregate
On Thu, 2008-03-06 at 12:32 +0530, sathiya psql wrote:
i had a table with 50 lakh record...
it has a column called oid ( obviously all the tables will have
this ), but while doing any operation it is getting slow because of
the number of records...
if i remove the oid column will i get
Actually it isn't obvious as oids have been deprecated for years.
no in my version it is now also available
What version of ancient PostgreSQL are you running exactly?
postgresql 7.4
i had a table with 50 lakh record...
it has a column called oid ( obviously all the tables will have this ), but
while doing any operation it is getting slow because of the number of
records...
if i remove the oid column will i get any benefit, what are all the other
default columns created
41 matches
Mail list logo
