From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | AW: More Performance |
Date: | 2000-05-25 08:31:59 |
Message-ID: | 219F68D65015D011A8E000006F8590C604AF7D9D@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> The cost estimation code is under active development, and if you check
> the pgsql list archives you will find lively discussions about its
> deficiencies ;-). But I'm having a hard time mustering much concern
> about whether it behaves optimally in the vacuum-but-no-vacuum-analyze
> case.
Here I must slightly disagree, if the impact of vacuum without analyze is so
bad,
then analyze should be the default for vacuum.
Maybe a better default selectivity would be datatype driven, like
int: 1/(2*maxint)
char(n): 1/(n*256)
....
I think this is what my favorite commercial DBMS does.
Because we have an extensible type system I guess this would be overdoing
it,
but in this light a much smaller default selectivity would seem more
appropriate
(like 1/100000).
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2000-05-25 09:08:41 | AW: Last call for comments: fmgr rewrite [LONG] |
Previous Message | Zeugswetter Andreas SB | 2000-05-25 08:03:43 | AW: AW: More Performance |