[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] estimating # of distinct values
From:       Alvaro Herrera <alvherre () commandprompt ! com>
Date:       2010-12-31 13:34:04
Message-ID: 1293802260-sup-5579 () alvh ! no-ip ! org
[Download RAW message or body]

Excerpts from Tom Lane's message of jue dic 30 23:02:04 -0300 2010:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > I was thinking that we could have two different ANALYZE modes, one
> > "full" and one "incremental"; autovacuum could be modified to use one or
> > the other depending on how many changes there are (of course, the user
> > could request one or the other, too; not sure what should be the default
> > behavior).
> 
> How is an incremental ANALYZE going to work at all?  It has no way to
> find out the recent changes in the table, for *either* inserts or
> deletes.  Unless you want to seqscan the whole table looking for tuples
> with xmin later than something-or-other ... which more or less defeats
> the purpose.

Yeah, I was thinking that this incremental ANALYZE would be the stream
in the "stream-based estimator" but evidently it doesn't work that way.
The stream that needs to be passed to the estimator consists of new
tuples as they are being inserted into the table, so this would need to
be done by the inserter process ... or it'd need to transmit the CTIDs
for someone else to stream them ... not an easy thing, in itself.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]