On 15 May 2013 16:35, Heikki Linnakangas wrote:

Shared memory space is limited, but we only need the watermarks for any
in-progress truncations. Let's keep them in shared memory, in a small
fixed-size array. That limits the number of concurrent truncations that can
be in-progress, but that should be ok. To not slow down common backend
operations, the values (or lack thereof) are cached in relcache. To sync the
relcache when the values change, there will be a new shared cache
invalidation event to force backends to refresh the cached watermark values.
A backend (vacuum) can ensure that all backends see the new value by first
updating the value in shared memory, sending the sinval message, and waiting
until everyone has received it.
I think we could use a similar scheme for 2 other use cases.

1. Unlogged tables. It would be useful to have a persistent "safe high
watermark" for an unlogged table. So in the event of a crash, we
truncate back to the safe high watermark, not truncate the whole
table. That would get updated at each checkpoint. Unlogged tables will
get much more useful with that change. (Issues, with indexes would
need to be resolved also).

2. Table extension during COPY operations is difficult. We need to be
able to extend in larger chunks, so we would need to change the
algorithm about how extension works. I'm thinking there's a
relationship there with watermarks.

Can we look at the needs of multiple areas at once, so we come up with
a more useful design that covers more than just one use case, please?

  Simon Riggs http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 17 of 17 | next ›
Discussion Overview
grouppgsql-hackers @
postedMay 15, '13 at 3:35p
activeMay 23, '13 at 12:22p



site design / logo © 2021 Grokbase