From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: AW: AW: Call for alpha testing: planner statistics revi sion s |
Date: | 2001-06-18 16:26:09 |
Message-ID: | 2207.992881569@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
> I mean, that it is probably not useful to maintain distribution statistics
> for a table that is that small at all (e.g. <= 3000 rows and less than
> 512 k size).
Actually, stats are quite interesting for smaller tables too. Maybe not
so much for the table itself (ie, deciding between seq and index scan is
not so critical), but to estimate sizes of joins against other tables.
>> Not if it takes hours to get the stats. I'm more interested in keeping
>> ANALYZE cheap and encouraging DBAs to run it frequently, so that the
>> stats stay up-to-date. It doesn't matter how perfect the stats were
>> when they were made, if the table has changed since then.
> That is true, but this is certainly a tradeoff situation. For a huge table
> that is quite static you would certainly want most accurate statistics even
> if it takes hours to compute once a month.
Sure. My thought is that one would do this by increasing the SET
STATISTICS targets for such tables, thus yielding more detailed stats
that take longer to compute. What we need now is experimentation to
find out how well this works in practice. It might well be that more
knobs will turn out to be useful, but let's not add complexity until
we've proven it to be necessary ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2001-06-18 16:56:44 | Problem with reading startup packet after fork |
Previous Message | Peter Eisentraut | 2001-06-18 16:24:36 | Re: UNIQUE INDEX unaware of transactions (a spin ofquestion) |