ISTM that "progress" and "progress_slice" only depend on num_scanned and
per-tablespace num_to_scan and total num_to_scan, so they are somehow
redundant and the progress could be recomputed from the initial figures
when needed.
They don't cause much space usage, and we access the values frequently.
So why not store them?
The same question would work the other way around: these values are one
division away, why not compute them when needed? No big deal.
[...] Given realistic amounts of memory the max potential "skew" seems
fairly small with float8. If we ever flush one buffer "too much" for a
tablespace it's pretty much harmless.
I do agree. I'm suggesting that a comment should be added to justify why
float8 accuracy is okay.
I see a binary_heap_allocate but no corresponding deallocation, this
looks like a memory leak... or is there some magic involved?
Hm. I think we really should use a memory context for all of this - we
could after all error out somewhere in the middle...
I'm not sure that a memory context is justified here, there are only two
mallocs and the checkpointer works for very long times. I think that it is
simpler to just get the malloc/free right.
[...] I'm not arguing for ripping it out, what I mean is that we don't
set a nondefault value for the GUCs on platforms with just
posix_fadivise available...
Ok with that.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
