Re: foreign key locks, 2nd attempt
От | Robert Haas |
---|---|
Тема | Re: foreign key locks, 2nd attempt |
Дата | |
Msg-id | CA+TgmoZx300pkRkL27-ejWAcHCp-6-1MuyMvotJZqX91qyzOtA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: foreign key locks, 2nd attempt (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: foreign key locks, 2nd attempt
Re: foreign key locks, 2nd attempt |
Список | pgsql-hackers |
On Thu, Mar 15, 2012 at 5:07 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Wed, Mar 14, 2012 at 5:23 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> You still have HEAP_XMAX_{INVALID,COMMITTED} to reduce the pressure on mxid >>> lookups, so I think something more sophisticated is needed to exercise that >>> cost. Not sure what. >> >> I don't think HEAP_XMAX_COMMITTED is much help, because committed != >> all-visible. > > So because committed does not equal all visible there will be > additional lookups on mxids? That's complete rubbish. Noah seemed to be implying that once the updating transaction committed, HEAP_XMAX_COMMITTED would get set and save the mxid lookup.But I think that's not true, because anyone who looksat the tuple afterward will still need to know the exact xmax, to test it against their snapshot. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: