Re: Refactoring the checkpointer's fsync request queue

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Shawn Debnath <sdn(at)amazon(dot)com>
Subject: Re: Refactoring the checkpointer's fsync request queue
Date: 2019-01-03 05:34:31
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Wed, Jan 2, 2019 at 11:40 AM Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> For the 0001 patch, I'll probably want to reconsider the naming a bit
> ("simple -> "specialized", "generic", ...?), refine (ability to turn
> off the small vector optimisation? optional MemoryContext? ability
> to extend without copying or zero-initialising at the same time?
> comparators with a user data parameter? two-value comparators vs
> three-value comparators? qsort with inline comparator? etc etc), and
> remove some gratuitous C++ cargo cultisms, and maybe also instantiate
> the thing centrally for some common types (I mean, perhaps 0002 should
> use a common uint32_vector rather than defining its own
> segnum_vector?).

Here's a new version that fixes a couple of stupid bugs (mainly a
broken XXX_lower_bound(), which I replaced with the standard algorithm
I see in many sources).

I couldn't resist the urge to try porting pg_qsort() to this style.
It seems to be about twice as fast as the original at sorting integers
on my machine with -O2. I suppose people aren't going to be too
enthusiastic about yet another copy of qsort in the tree, but maybe
this approach (with a bit more work) could replace the Perl code-gen
for tuple sorting. Then the net number of copies wouldn't go up, but
this could be used for more things too, and it fits with the style of
simplehash.h and simplevector.h. Thoughts?

Thomas Munro

Attachment Content-Type Size
0001-Add-parameterized-vectors-and-sorting-searching-s-v6.patch application/octet-stream 18.7 KB
0002-Refactor-the-fsync-machinery-to-support-future-SM-v6.patch application/octet-stream 81.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2019-01-03 05:53:55 Re: emacs configuration for new perltidy settings
Previous Message Amit Kapila 2019-01-03 03:58:12 Re: Logical decoding for operations on zheap tables