Re: Some ideas about Vacuum

On Jan 10, 2008 3:43 PM, Markus Schiltknecht <markus(at)bluegap(dot)ch> wrote:

> Hi,
>
> Gokulakannan Somasundaram wrote:
> > But i am just thinking of creating the DSM
> > by reading through the WAL Logs, instead of asking the Inserts, updates
> > and deletes to do the DSM creation.
>
> What's the advantage of that? What's wrong with collecting the
> information for DSM at transaction processing time? The overhead is
> certainly smaller than the overhead for doing it later on.

The overhead ..... is because of the contention. Am i missing something
here? While Vacuum is reading the DSM, operations may not be able to update
the bits. We need to put the DSM in shared memory, if all the processes are
going to update it, whereas if Vacuum is going to form the DSM, then it
might well be in the process local memory. I can think of things like False
sharing which might be avoided. But i think the main stuff is contention.

>
>
> > I think what Gregory is coming at is, "if we schedule the Vacuum
> > after 20% of table changes, then we essentially say we need 120% of the
> > disk space and hence our select operations might end up doing more
> I/Os."
>
> Well, full sequential scans end up doing more I/O, but not index scans
> typical for OLTP. So if autovacuum is the only thing doing full
> sequential scans, you'd better reduce the number of full scans, instead
> of saving only some percentage per scan, no?

Even in indexes, we might end up reading dead tuples. We would mark it with
LP_DEAD. So the overhead is less, but its there. Ofcourse its natural to
think of some background jobs during OLTP, and they will be affected

>
>
> Of course, depending on how much of your table fits in ram, you also
> need to consider the space savings in RAM... However, I'm assuming a
> reasonably low ratio of RAM size vs table size.

That's another one.

Thanks,
Gokul.