Re: Patch: Write Amplification Reduction Method (WARM)

Поиск
Список
Период
Сортировка
От Pavan Deolasee
Тема Re: Patch: Write Amplification Reduction Method (WARM)
Дата
Msg-id CABOikdOq0FdT+pewqoCX5pB-nJcs++ekXOTZijTYAwwNk0TTvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Patch: Write Amplification Reduction Method (WARM)  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers


On Sat, Apr 1, 2017 at 12:39 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
On Thu, Mar 30, 2017 at 4:13 AM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:


On Thu, Mar 30, 2017 at 3:29 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
On Wed, Mar 29, 2017 at 11:51 AM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
> Thanks. I think your patch of tracking interesting attributes seems ok too
> after the performance issue was addressed. Even though we can still improve
> that further, at least Mithun confirmed that there is no significant
> regression anymore and in fact for one artificial case, patch does better
> than even master.

I was trying to compile these patches on latest
head(f90d23d0c51895e0d7db7910538e85d3d38691f0) for some testing but I
was not able to compile it.

make[3]: *** [postgres.bki] Error 1

Looks like OID conflict to me.. Please try rebased set.

broken again on oid conflicts for 3373 to 3375 from the monitoring permissions commi 25fff40798fc4.


Hi Jeff,

Thanks for trying. Much appreciated,
 
After bumping those, I get these compiler warnings:

heapam.c: In function 'heap_delete':
heapam.c:3298: warning: 'root_offnum' may be used uninitialized in this function
heapam.c: In function 'heap_update':
heapam.c:4311: warning: 'root_offnum' may be used uninitialized in this function
heapam.c:4311: note: 'root_offnum' was declared here
heapam.c:3784: warning: 'root_offnum' may be used uninitialized in this function
heapam.c: In function 'heap_lock_tuple':
heapam.c:5087: warning: 'root_offnum' may be used uninitialized in this function


Thanks. I don't see them on my LLVM compiler even at -O2. Anyways, I inspected. They all looked non-problematic, but fixed in the attached version v24, along with some others I could see on another linux machine.
 

And I get a regression test failure, attached.


Thanks again. Seems like my last changes to disallow WARM updates if more than 50% indexes are updated caused this regression. Having various features in different branches and merging them right before sending out the patchset was probably not the smartest thing to do. I've fixed the regression simply by adding another index on that table and making changes to the expected output.

BTW I still need 2 regression failures, but I see them on the master too, so not related to the patch. Attached here.

Thanks,
Pavan 
Вложения

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Partitioning vs ON CONFLICT
Следующее
От: Ashutosh Sharma
Дата:
Сообщение: Re: [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint