On Jan 10, 2008 3:43 PM, Markus Schiltknecht <
markus@bluegap.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.