Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
| От | Alvaro Herrera |
|---|---|
| Тема | Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
| Дата | |
| Msg-id | 20160615194059.GA23975@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < (Kevin Grittner <kgrittn@gmail.com>) |
| Ответы |
Re: [HACKERS] Re: pgsql: Avoid extra locks in
GetSnapshotData if old_snapshot_threshold <
Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
| Список | pgsql-committers |
Kevin Grittner wrote: > On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: > > We actually go quite some lengths to support this case, even when it's > > the opinion of many that we shouldn't. For example VACUUM doesn't try > > to find index entries using the values in each deleted tuple; instead we > > remember the TIDs and then scan the indexes (possibly many times) to > > find entries that match those TIDs -- which is much slower. Yet we do > > it this way to protect the case that somebody is doing the > > not-really-IMMUTABLE function. > > > > In other words, I don't think we consider the position you argued as > > acceptable. > > What are you saying is unacceptable, and what behavior would be > acceptable instead? The answer "we don't support the situation where you have an index using an IMMUTABLE function that isn't actually immutable" is not acceptable. The acceptable solution would be a design that doesn't have that property as a requisite. I think having various executor(/heapam) checks that raise errors when queries are executed from within ANALYZE is acceptable. I don't know about the TOAST related angle Andres just raised. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-committers по дате отправления: