Skip site navigation (1) Skip section navigation (2)

Re: estimating # of distinct values

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Tomas Vondra" <tv(at)fuzzy(dot)cz>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: estimating # of distinct values
Date: 2010-12-27 22:55:12
Message-ID: 7214.1293490512@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> With respect to (b), I think I'd need to see a much more detailed
>> design for how you intend to make this work.  Off the top of my
>> head there seems to be some pretty serious feasibility problems.
 
> I had one random thought on that -- it seemed like a large concern
> was that there would need to be at least an occasional scan of the
> entire table to rebuild the distinct value information.  Don't we
> already require an occasional scan of the entire table for freezing
> transaction IDs?  Could this be part of any vacuum of the entire
> table?

Well, first, those scans occur only once every few hundred million
transactions, which is not likely a suitable timescale for maintaining
statistics.  And second, we keep on having discussions about rejiggering
the whole tuple-freezing strategy.  Even if piggybacking on those scans
looked useful, it'd be unwise to assume it'll continue to work the same
way it does now.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2010-12-27 23:04:20
Subject: Re: estimating # of distinct values
Previous:From: Kevin GrittnerDate: 2010-12-27 22:49:51
Subject: Re: estimating # of distinct values

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group