The Last Optimization

Поиск
Список
Период
Сортировка
От Areski Belaid
Тема The Last Optimization
Дата
Msg-id OE39thPZJCqJHY9hvSg00002104@hotmail.com
обсуждение исходный текст
Ответ на Re: The Last Optimization  ("scott.marlowe" <scott.marlowe@ihs.com>)
Ответы Re: The Last Optimization  ("scott.marlowe" <scott.marlowe@ihs.com>)
Re: The Last Optimization  (Bill Gribble <grib@linuxdevel.com>)
Список 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 по дате отправления:

Предыдущее
От: "Ian Harding"
Дата:
Сообщение: Re: MS SQL Server 2000 migrate to Postgres 7.x
Следующее
От: "scott.marlowe"
Дата:
Сообщение: Re: The Last Optimization