Re: [pgsql-performance] Is dump-reload the only cure?

Поиск
Список
Период
Сортировка
От Rod Taylor
Тема Re: [pgsql-performance] Is dump-reload the only cure?
Дата
Msg-id 1036155160.3550.8.camel@jester
обсуждение исходный текст
Ответ на Is dump-reload the only cure?  (<mallah@trade-india.com>)
Список pgsql-admin
On Fri, 2002-11-01 at 06:15, mallah@trade-india.com wrote:


Looks like a borderline case.  See the costs of the index scan and
sequential scan are very similar.  Since 499 covers nearly 1 in 10
tuples, it's likely found on nearly every page.  This should make a
sequential scan much cheaper.

However, if the data is clumped together (not distributed throughout the
table) than an index scan may be preferable.   So...  CLUSTER may be
useful to you.

In the future please 'explain analyze' the queries you're looking at to
see actual costs as compared to the estimated cost.


>       499 | 25010
>       501 |  3318
>
>
> before dump reload:
> tradein_clients=# VACUUM VERBOSE ANALYZE email_bank_mailing_lists;
> NOTICE:  --Relation email_bank_mailing_lists--
> NOTICE:  Pages 3583: Changed 0, Empty 0; Tup 256419: Vac 0, Keep 0, UnUsed 44822.
>         Total CPU 0.24s/0.04u sec elapsed 0.30 sec.
> NOTICE:  Analyzing email_bank_mailing_lists
> VACUUM
> tradein_clients=# explain SELECT count( email_id  )  from email_bank_mailing_lists   where
> query_id=499;NOTICE:  QUERY PLAN:
>
> Aggregate  (cost=6863.24..6863.24 rows=1 width=4)
>   ->  Seq Scan on email_bank_mailing_lists  (cost=0.00..6788.24 rows=30001 width=4)
>
> EXPLAIN

--
  Rod Taylor


В списке pgsql-admin по дате отправления:

Предыдущее
От: mail2stern@gmx.net (Stefan Stern)
Дата:
Сообщение: readline.h / history.h error at ./configure
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: [pgsql-performance] Is dump-reload the only cure?