Re: Optimizer Question/Suggestion

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Optimizer Question/Suggestion
Date: 2002-11-03 01:30:15
Message-ID: 5.1.0.14.0.20021103120922.029c3cb8@mail.rhyme.com.au
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 09:36 AM 2/11/2002 -0500, Tom Lane wrote:

>Why not do frequent non-full vacuums on only that table, perhaps every
>five minutes or so? That's certainly the direction that development is
>headed in (we just haven't automated the vacuuming yet).

Done this now, and I'll wait for a new high load time to see how big the
table gets.

Definitely looking forward integrated on-line vacuum!

>Ideally we should never let a table get so overloaded with dead space
>that this strategy would be profitable.

I suspect it would be more common that you might hope, both because of
incompetance/changed database usage (as in this case) and archival
strategies (ie. deleting data periodically, but *not* doing a full vacuum).
I come from a background where pre-allocating unused space for table data
is a good strategy, not a performance killer, and I'm probably not alone.

If it was not hard, I thought adding a PK scan as a possible strategy when
considering seqscan was an interesting option. I suppose the other option
in this case would be to modify seqscan to only look at pages we know have
records (if we keep that data?).

>BTW, the system does not actually have any stats about dead tuples.
>What it knows about are live tuples and total disk pages occupied by
>the table.

So what made it choose the index scan? Does it make guesses about tuple
sizes, and predict empty space?

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2002-11-03 01:49:56 Re: CONVERT function is seriously broken
Previous Message Bruce Momjian 2002-11-03 01:29:42 Re: missing const it PQexscapeBytea/PQunescapeBytea in 7.3b3