Re: AW: [HACKERS] Really slow query on 6.4.2 - Mailing list pgsql-hackers

From geek+@cmu.edu
Subject Re: AW: [HACKERS] Really slow query on 6.4.2
Date
Msg-id emacs-smtp-4003-14079-56696-133313@export.andrew.cmu.edu
Whole thread Raw
In response to Re: AW: [HACKERS] Really slow query on 6.4.2  (The Hermit Hacker <scrappy@hub.org>)
List 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 by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] Really slow query on 6.4.2
Next
From: Vince Vielhaber
Date:
Subject: Re: [HACKERS] libpq++