Re: SSI performance

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: SSI performance
Дата
Msg-id 4D4BEB66020000250003A3F6@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: SSI performance  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
I wrote:
> I just had a thought -- we already have the LocalPredicateLockHash
> HTAB to help with granularity promotion issues without LW
> locking.  Offhand, I can't see any reason we couldn't use this for
> an initial check for a relation level lock, before going through
> the more rigorous pass under cover of the locks.  We won't have a
> relation lock showing in the local table if it never was taken
> out, and it won't go away until the end of transaction (unless the
> whole transaction is deamed safe from SSI conflicts and everything
> is cleaned up early).
>  
> Dan, does that look sane to you, or am I having another "senior
> moment" here?
>  
> If this works, it would be a very minor change, which might
> eliminate a lot of that overhead for many common cases.
To make this more concrete:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=91d93734b8a84cf54e77f8d30b26afde7cc43218
I *think* we should be able to do this with the page lock level,
too; but I'd like Dan to weigh in on that before putting something
out there for that.  He did the local lock table work, and will be
in a better position to know how safe this is.  Also, while it's
pretty clear this should be a win at the relation level, it's not as
clear to me whether adding this for the page level will be a net
gain.
-Kevin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: multiset patch review
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: keeping a timestamp of the last stats reset (for a db, table and function)