<disclaimer>I'M NOT POSTGRES HACKER. THIS IS JUST NA INTUITION.
</disclaimer>
W dniu 15.09.2017 o 21:30, Christopher Browne pisze:
> On 15 September 2017 at 14:45, Adam Brusselback
> <adambrusselback@gmail.com> wrote:
[-----------]
>
> b) Referencing which index entries can be dropped (e.g. - vacuumed out)
> is a fair bit more complex because the index entries depend on multiple
> tables. This adds, um, concurrency complications, if data is being deleted
> from multiple tables concurrently. (Over-simplifying question: "When
> a table that participates in the sharing is vacuumed, does the shared
> index get vacuumed? What if two such tables are vacuumed concurrently?")
This is probably postgresql-hackers knowledge, but I'd appreciate if you
elaborate: why "concurrent vacuum" of two table with common index is
such a problem?
1. why cannot it be "serialized on demand" in such case/exception (e.i
the case of tables being bond by a common index)? In other words, can
the initial concurrency be turned into serialized commands?
2. why common index cannot be implemented as "split files" - locking
with their respective tables the usual way? The problem of concurrent
locking would vanish at the expense of performance hit ... but if
someone desperately needs such "global index", I'd bet he/she will live
with performance hit. I would.
-R
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general