Re: zheap: a new storage format for PostgreSQL

Поиск
Список
Период
Сортировка
От Satyanarayana Narlapuram
Тема Re: zheap: a new storage format for PostgreSQL
Дата
Msg-id MWHPR21MB08293C04711704C0B7271C8A91C60@MWHPR21MB0829.namprd21.prod.outlook.com
обсуждение исходный текст
Ответ на Re: zheap: a new storage format for PostgreSQL  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: zheap: a new storage format for PostgreSQL  (Hartmut Holzgraefe <hartmut.holzgraefe@gmail.com>)
Re: zheap: a new storage format for PostgreSQL  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers


>> Cons

>> -----------
>> 1. Deletes can be somewhat expensive.
>> 2. Transaction aborts will be expensive.
>> 3. Updates that update most of the indexed columns can be somewhat expensive.

Given transaction aborts are expensive, is there any impact on the crash recovery? Did you perform any tests on the recovery duration?

Thanks,
Satya




From: Amit Kapila <amit.kapila16@gmail.com>
Sent: Thursday, March 1, 2018 7:05:12 AM
To: PostgreSQL Hackers
Subject: Re: zheap: a new storage format for PostgreSQL
 
On Thu, Mar 1, 2018 at 7:39 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> Preliminary performance results
> -------------------------------------------
>

I have not used plain text mode in my previous email due to which
performance results might not be clear in some email clients, so
attaching it again in the form of pdf.

--
With Regards,
Amit Kapila.
EnterpriseDB: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.enterprisedb.com&data=04%7C01%7CSatyanarayana.Narlapuram%40microsoft.com%7Cad676656345544116aa008d57f85e87d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636555135932006655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=7z7XUUdXr3CZe71y%2F7kVto%2BzJB5IogypcRHODu8yAu0%3D&reserved=0

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

Предыдущее
От: Erik Rijkers
Дата:
Сообщение: Re: row filtering for logical replication
Следующее
От: Tom Lane
Дата:
Сообщение: Re: CALL optional in PL/pgSQL