The Last Optimization - Mailing list pgsql-general

From Areski Belaid
Subject The Last Optimization
Date
Msg-id OE39thPZJCqJHY9hvSg00002104@hotmail.com
Whole thread Raw
In response to Re: The Last Optimization  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: The Last Optimization
Re: The Last Optimization
List 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

pgsql-general by date:

Previous
From: "Ian Harding"
Date:
Subject: Re: MS SQL Server 2000 migrate to Postgres 7.x
Next
From: "scott.marlowe"
Date:
Subject: Re: The Last Optimization