"Dawid Kuroczko" <[EMAIL PROTECTED]> wrote:
> I am sure the idea is not original, yet still I would like to know how hard
> would it be to support local (per table) oldest visible XIDs.
>
> I mean, when transaction start you need to keep all tuples with xmin >=
> oldest_xid in all tables, becaus
On Feb 19, 2008 8:31 AM, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > > In my workload, ANALYZE takes long time (1min at statistics_target = 10,
> > > and 5min at 100), but the updated table needs to be vacu
Gregory Stark <[EMAIL PROTECTED]> wrote:
> > 4. ANALYZE finishes in a short time.
> There was a paper with a nice algorithm posted a while back which required
> only constant memory but it depended on scanning the entire table. I think to
> do n_distinct estimates we'll need some statistics which
"ITAGAKI Takahiro" <[EMAIL PROTECTED]> writes:
> 4. ANALYZE finishes in a short time.
>It is ok that VACUUM takes a long time because it is not a transaction,
>but ANALYZE should not. It requres cleverer statistics algorithm.
>Sampling factor 10 is not enough for pg_stats.n_distinct. W
Tom Lane <[EMAIL PROTECTED]> wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > In my workload, ANALYZE takes long time (1min at statistics_target = 10,
> > and 5min at 100), but the updated table needs to be vacuumed every 30
> > seconds
> > because seqscans run on the table repeatedly.
>
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> In my workload, ANALYZE takes long time (1min at statistics_target = 10,
> and 5min at 100), but the updated table needs to be vacuumed every 30 seconds
> because seqscans run on the table repeatedly.
There is something *seriously* wrong with that. I
