Re: BUG #1697: Select getting slower on continously updating data

Поиск
Список
Период
Сортировка
От Bruno Wolff III
Тема Re: BUG #1697: Select getting slower on continously updating data
Дата
Msg-id 20050603144951.GA10195@wolff.to
обсуждение исходный текст
Ответ на Re: BUG #1697: Select getting slower on continously updating data  (Bruno Wolff III <bruno@wolff.to>)
Список pgsql-novice
On Fri, Jun 03, 2005 at 00:09:00 -0700,
  Bahadur Singh <bahadursingh@yahoo.com> wrote:
>
> Many thanks for this tip !
> But is this good idea to analyse/vacuuming the
> database tables while updates are taking place..
> Since, I update continuously say (100,000 ) times or
> more the same data set.
>
> This is the result of analyze command.
>
> INFO:  analyzing "public.salesarticle"
> INFO:  "salesarticle": scanned 3000 of 20850 pages,
> containing 62 live rows and 134938 dead rows; 62 rows
> in sample, 431 estimated total rows
>
> Gesamtlaufzeit der Abfrage: 5531 ms.
> Total Time Taken : 5531 ms.
>
> Can you suggest me some clever way to so, because I
> would prefer to do vaccumming while database is not
> loaded with queries/transactions.

While that may be a nice preference, under your usage pattern that does
not appear to be a good idea. As long as your disk I/O isn't saturated
you want to be running vacuums a lot more often than you are. (Analyze should
only be needed if the distrution of values is changing constantly. An example
would be timestamps indicating when an update occured.)

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

Предыдущее
От: tövis
Дата:
Сообщение: ecpg use or not
Следующее
От: Babak Asadi
Дата:
Сообщение: Wrong SQLSTATE returned?