Re: reloption to prevent VACUUM from truncating empty pages at theend of relation

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Дата
Msg-id CAA4eK1LNK39EfeDJQomy4wioAkbop_g4kL0WS48RdGWrYEnDog@mail.gmail.com
обсуждение исходный текст
Ответ на Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Andres Freund <andres@anarazel.de>)
Ответы Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Wed, Apr 18, 2018 at 7:46 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2018-04-18 10:46:51 +0900, Michael Paquier wrote:
>> On Tue, Apr 17, 2018 at 06:13:31PM -0700, Andres Freund wrote:
>> > Not sure what you mean?
>>
>> Do you need help on it?  I suggest that I could undertake the proposed
>> patch and submit it earlier in the development cycle of v12.
>
> I think it's at the very least two months of serious development work to
> get it into a state ready for submission. And a good chunk of that not
> even sketched out.  Replacing the hashtable is the easy part, the memory
> management (Complicated due to lock-freeness. I'm thinking of using a
> variant of epoch based reclamation) isn't really there, the management
> of shared "open relations" state are the hard parts...
>
> So yes, I could use help on it, but it'll be a lot of actual design and
> investigatory work.
>

I think it makes sense to pursue that approach, but it might be worth
considering some alternative till we have it.  I remember last time
(in 2015) we have discussed some another solution [1] to this problem
(or similar) and we have left it unattended in the hope that we will
get a better solution, but we are still in the same situation.  I
think in general it is better to go with the approach which can fix
the root cause of the problem, but if that is going to take a long
time, it is not terrible to provide some workable solution which can
help users.


[1] - https://www.postgresql.org/message-id/CAA4eK1JPLGjpMeJ5YLNE7bpNBhP2EQe_rDR%2BAw3atNfj9WkAGg%40mail.gmail.com

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


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

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Postgres stucks in deadlock detection
Следующее
От: Vladimir Borodin
Дата:
Сообщение: Re: Built-in connection pooling