Re: AW: [HACKERS] Really slow query on 6.4.2

Поиск
Список
Период
Сортировка
От geek+@cmu.edu
Тема Re: AW: [HACKERS] Really slow query on 6.4.2
Дата
Msg-id emacs-smtp-4003-14079-56696-133313@export.andrew.cmu.edu
обсуждение исходный текст
Ответ на Re: AW: [HACKERS] Really slow query on 6.4.2  (The Hermit Hacker <scrappy@hub.org>)
Список pgsql-hackers
Then <scrappy@hub.org> spoke up and said:
> On 25 Mar 1999 geek+@cmu.edu wrote:
> > They are definitely *not* worth the cost.  Especially since no table
> > will have the default 0 rows entry after a single vacuum analyze of
> > that table.  Let's be honest: if you aren't interested in doing a
> > vacuum, then really aren't interested in performance, anyway.
> 
> What I personally am not interested in is having to spend 20 minute per
> day with a totally locked up database because I want my queries to be
> faster, when there are other ways of doing it...

Uhm, no.  The specific case we are talking about here is creation of a
table, inserting rows into it, and NEVER running vacuum analyze on
it.  This would not lock up your database for 20 minutes unless you
are dropping and re-creating a bunch of tables.  Even that case could
be scripted creatively[0], though.  Further, you don't have to run it
on a whole database every night.  Just the tables of interest.

We run a multi-gigabyte Ingres database her for our student systems.
When we want to make sure that good plans are chosen, we sysmod and
optimizedb it.  Since we always want good plans, but rarely inload
massive amounts of data, we do this once a week.

One of the things to be kept in mind with performance tuning is
tradeoffs.  Does it make sense to penalize every transaction for the
sake of updating statistics?  (the answer is "maybe") Does it make
sense to penalize every transaction to provide a recovery mechanism?
(yes) Does it make sense to penalize every transaction to prevent any
one transaction from using up more than 1MB/s of bandwidth?  (no)
Should you extract the data to a binary flat file, read it in C,
collect the information of interest and then do something interesting
with it?  (maybe)

[0] Assuming the data are laid out "sequentially" on the index fields:
create the table, chop off and insert only the first and last
thousand[1] rows, vacuum, and then insert the rest.

[1] Or perhaps a slightly bigger number.  Or a sampling of the file

-- 
=====================================================================
| JAVA must have been developed in the wilds of West Virginia.      |
| After all, why else would it support only single inheritance??    |
=====================================================================
| Finger geek@cmu.edu for my public key.                            |
=====================================================================



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

Предыдущее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] Really slow query on 6.4.2
Следующее
От: Vince Vielhaber
Дата:
Сообщение: Re: [HACKERS] libpq++