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
Re: The Last Optimization |
Список | 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 по дате отправления: