From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
Cc: | Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Vacuum, analyze, and setting reltuples of pg_class |
Date: | 2006-12-13 21:40:47 |
Message-ID: | 11898.1166046047@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> On Mon, Dec 11, 2006 at 12:08:30PM -0500, Tom Lane wrote:
>> "Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
>>> Short version: is it optimal for vacuum to always populate reltuples
>>> with live rows + dead rows?
>>
>> If we didn't do that, it would tend to encourage the use of seqscans on
>> tables with lots of dead rows, which is probably a bad thing.
> So then why does vacuum do that? ISTM that it makes more sense for it to
> act the same as analyze and only count live rows.
I think what you misread what I said: it's better to have the larger
count in reltuples so that the planner won't try to use a seqscan when
there are, say, 3 live tuples and 100K dead ones. The real problem is
that analyze ought to act more like vacuum, but since it presently
ignores deaders altogether, it fails to.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-12-13 21:46:46 | Re: Operator class group proposal |
Previous Message | Tom Lane | 2006-12-13 21:32:52 | Re: Better management of mergejoinable operators |