Re: [HACKERS] Some notes on optimizer cost estimates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
Date: 2000-01-21 03:10:28
Message-ID: 27077.948424228@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> It is nice that ANALYZE is done during vacuum. I can't imagine why you
> would want to do an analyze without adding a vacuum to it. I guess
> that's why I made them the same command.

Well, the main bad thing about ANALYZE being part of VACUUM is that
it adds to the length of time that VACUUM is holding an exclusive
lock on the table. I think it'd make more sense for it to be a
separate command.

I have also been thinking about how to make ANALYZE produce a more
reliable estimate of the most common value. The three-element list
that it keeps now is a good low-cost hack, but it really doesn't
produce a trustworthy answer unless the MCV is pretty darn C (since
it will never pick up on the MCV at all until there are at least
two occurrences in three adjacent tuples). The only idea I've come
up with is to use a larger list, which would be slower and take
more memory. I think that'd be OK in a separate command, but I
hesitate to do it inside VACUUM --- VACUUM has its own considerable
memory requirements, and there's still the issue of not holding down
an exclusive lock longer than you have to.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2000-01-21 03:11:52 Re: Date/time type
Previous Message Hiroshi Inoue 2000-01-21 02:59:20 RE: [HACKERS] Some notes on optimizer cost estimates