Re: Improving replay of XLOG_BTREE_VACUUM records

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Improving replay of XLOG_BTREE_VACUUM records
Дата
Msg-id CANP8+jK0GP=ES+EF8nhnEgJ8PaHSR8j52sbL20yvcABkPGBuew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improving replay of XLOG_BTREE_VACUUM records  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Improving replay of XLOG_BTREE_VACUUM records  (Vladimir Borodin <root@simply.name>)
Список pgsql-hackers
On 10 March 2016 at 06:27, Michael Paquier <michael.paquier@gmail.com> wrote:
On Thu, Mar 10, 2016 at 1:29 AM, David Steele <david@pgmasters.net> wrote:
> On 1/8/16 9:34 AM, Alvaro Herrera wrote:
>> Simon Riggs wrote:
>>>
>>> On 8 January 2016 at 13:36, Alvaro Herrera <alvherre@2ndquadrant.com>
>>> wrote:
>>>>
>>>> I would agree except for the observation on toast indexes.  I think
>>>> that's an important enough use case that perhaps we should have both.
>>>
>>> The exclusion of toast indexes is something we can remove also, I have
>>> recently discovered. When we access toast data we ignore MVCC, but we
>>> still
>>> have the toast pointer and chunkid to use for rechecking our scan
>>> results.
>>> So a later patch will add some rechecks.
>>
>> Ah, interesting, glad to hear.  I take it you're pushing your patch
>> soon, then?
>
> ISTM that this patch should be "returned with feedback" or "rejected" based
> on the thread.  I'm marking it "waiting for author" for the time being.

I think that we are still waiting for some input from Simon here...
Simon, are you going to finish wrapping up your other patch?

Yes, I have done the research, so think patch should be rejected now.

Thanks to everyone for their input. It's good to have alternate approaches.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Floating point timestamps
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: Relation extension scalability