| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mary Edie Meredith <maryedie(at)osdl(dot)org> |
| Cc: | pgsql-performance <pgsql-performance(at)postgresql(dot)org>, osdldbt-general <osdldbt-general(at)lists(dot)sourceforge(dot)net> |
| Subject: | Re: [GENERAL] how to get accurate values in pg_statistic (continued) |
| Date: | 2003-09-04 23:16:15 |
| Message-ID: | 11537.1062717375@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Mary Edie Meredith <maryedie(at)osdl(dot)org> writes:
> Stephan Szabo kindly responded to our earlier queries suggesting we look
> at default_statistics_target and ALTER TABLE ALTER COLUMN SET
> STATISTICS.
> These determine the number of bins in the histogram for a given column.
> But for a large number of rows (for example 6 million) the maximum value
> (1000) does not guarantee that ANALYZE will do a full scan of the table.
> We do not see a way to guarantee the same statistics run to run without
> forcing ANALYZE to examine every row of every table.
Do you actually still have a problem with the plans changing when the
stats target is above 100 or so? I think the notion of "force ANALYZE
to do a full scan" is inherently wrongheaded ... it certainly would not
produce numbers that have anything to do with ordinary practice.
If you have data statistics that are so bizarre that the planner still
gets things wrong with a target of 1000, then I'd like to know more
about why.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Conway | 2003-09-04 23:50:24 | Re: [GENERAL] how to get accurate values in pg_statistic |
| Previous Message | Relaxin | 2003-09-04 23:14:50 | Re: SELECT's take a long time compared to other DBMS |