Re: Proposal for CSN based snapshots
От | Robert Haas |
---|---|
Тема | Re: Proposal for CSN based snapshots |
Дата | |
Msg-id | CA+TgmobaHXcz+5cN9pFS5rVQNkxg9fuCD0poypas_auhUB4VDQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal for CSN based snapshots (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Proposal for CSN based snapshots
|
Список | pgsql-hackers |
Nice to see you working on this again. On Mon, Aug 22, 2016 at 12:35 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > A sequential scan of a table like that with 10 million rows took about 700 > ms on my laptop, when the hint bits are set, without this patch. With this > patch, if there's a snapshot holding back the xmin horizon, so that we need > to check the CSN log for every XID, it took about 30000 ms. So we have some > optimization work to do :-). I'm not overly worried about that right now, as > I think there's a lot of room for improvement in the SLRU code. But that's > the next thing I'm going to work. So the worst case for this patch is obviously bad right now and, as you say, that means that some optimization work is needed. But what about the best case? If we create a scenario where there are no open read-write transactions at all and (somehow) lots and lots of ProcArrayLock contention, how much does this help? Because there's only a purpose to trying to minimize the losses if there are some gains to which we can look forward. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: