The Last Optimization

From: "Areski Belaid" <areski5(at)hotmail(dot)com>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, "PostgreSQL-General" <pgsql-general(at)postgresql(dot)org>, "Gregory Wood" <gregw(at)com-stock(dot)com>, "Mario Weilguni" <mweilguni(at)sime(dot)com>
Subject: The Last Optimization
Date: 2002-09-06 17:09:31
Message-ID: OE39thPZJCqJHY9hvSg00002104@hotmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

First Thanks for all of your advice, It's really nice to get so much help...

I follow some advice and after try to do some EXPLAIN ANALYSE on every
queries, I realyse that
a "SELECT with LIMITE" (ie 50 100) is really fast quiet immediate...
BUT That's create the problem in my application is the SELECT COUNT.

Ok, I did some "select count" on few hundred thousand of instance (million
some time)...
The "select count" have to check all of them and it's not the case with
"LIMIT"! Right ?

EXPLAIN ANALYZE SELECT count(*) FROM "Data" WHERE ("IDOrigin" IN ('16',
'20', '21', '18', '13', '17', '15', '19'));

NOTICE: QUERY PLAN:

Aggregate (cost=188017.51..188017.51 rows=1 width=0) (actual
time=72071.90..72071.90 rows=1 loops=1)
-> Seq Scan on Email (cost=0.00..185740.10 rows=910965 width=0) (actual
time=15988.85..71825.27 rows=183065 loops=1)
Total runtime: 72072.12 msec

72 secondes for a php/pg application is useless.

So which is the way, I need the "select count" to kwon the globaly number, I
can avoid of this information...
A cache solution, would be impossible, my search engine is really complex...
So maybe split the table in different other table, but it's going to take
one week of work if I have to change
all the queries...

So, I m a less lost but always without solution, every help would nice...

Best regards, Areski

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message scott.marlowe 2002-09-06 17:25:41 Re: The Last Optimization
Previous Message Ian Harding 2002-09-06 17:00:15 Re: MS SQL Server 2000 migrate to Postgres 7.x