Re: logical changeset generation v6.1
От | Robert Haas |
---|---|
Тема | Re: logical changeset generation v6.1 |
Дата | |
Msg-id | CA+TgmoZ29eTR2nfTQiiNwD7nBh7MASH=qWuafhwA5PhVewo_Xw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: logical changeset generation v6.1 (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: logical changeset generation v6.1
|
Список | pgsql-hackers |
On Tue, Oct 1, 2013 at 1:56 PM, Andres Freund <andres@2ndquadrant.com> wrote: > On 2013-10-01 10:07:19 -0400, Robert Haas wrote: >> - It seems that HeapSatisfiesHOTandKeyUpdate is now >> HeapSatisfiesHOTandKeyandCandidateKeyUpdate. Considering I think this >> was merely HeapSatisfiesHOTUpdate a year ago, it's hard not to be >> afraid that something unscalable is happening to this function. On a >> related node, any overhead added here costs broadly; I'm not sure if >> there's enough to worry about. > > Ok, I had to think a bit, but now I remember why I think these changes > are not really problem: Neither the addition of keys nor candidate keys > will add any additional comparisons since the columns compared for > candidate keys are a subset of the set of key columns which in turn are a > subset of the columns checked for HOT. Right? TBH, my primary concern was with maintainability more than performance. On performance, I think any time you add code it's going to cost somehow. However, it might not be enough to care about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: