On Sat, Sep 19, 2020 at 1:30 PM Tom Lane wrote:
> I wrote:
> > ISTM that getting rid of the division obviates the concern that the
> > nentries condition is too expensive,
True, that comment needed to go.
> Also, we could make it slightly cheaper yet, by changing the condition
> to
>
>
I wrote:
> ISTM that getting rid of the division obviates the concern that the
> nentries condition is too expensive,
Also, we could make it slightly cheaper yet, by changing the condition
to
hctl->freeList[0].nentries > (long) (hctl->max_bucket)
ie drop the +1. I'd argue that this
Thomas Munro writes:
> Pushed. Thanks Jakub, everyone.
BTW, looking over this patch, I wonder about
/*
* Can't split if running in partitioned mode, nor if frozen, nor if
* table is the subject of any active hash_seq_search scans. Strange
* order of these tes
On Tue, Sep 15, 2020 at 9:56 AM Thomas Munro wrote:
> > I looked over the patch and the only thing I saw was that we might
> > also want to remove the following line:
> >
> > #define DEF_FFACTOR1 /* default fill factor */
>
> Right, thanks. Fixed in the attached.
Pushed. Thanks Jakub, every
On Mon, Sep 14, 2020 at 11:35 PM David Rowley wrote:
> I just did some benchmarking with this patch using the same recovery
> benchmark that I used in [1] and also the two patches that I posted in
> [2]. Additionally, I added a PANIC at the end of recovery so that I
> could repeat the recovery ove
On Thu, 10 Sep 2020 at 14:55, Thomas Munro wrote:
>
> I wrote a draft commit message for Jakub's proposed change (attached),
> and did a little bit of testing, but I haven't seen a case where it
> wins yet; I need to work on something else now but thought I'd share
> this much anyway. One observa
On Tue, Sep 8, 2020 at 11:17 PM Jakub Wartak wrote:
> I agree with both, I just thought it might be interesting finding as this
> idiv might be (?) present in other common paths like ReadBuffer*() /
> PinBuffer() (some recent discussions, maybe on NUMA boxes), not just WAL
> recovery as it seem
fer*() / PinBuffer()
(some recent discussions, maybe on NUMA boxes), not just WAL recovery as it
seems relatively easy to improve.
-J.
[1] - https://github.com/macdice/redo-bench
[2] - https://fuhrwerks.com/csrg/info/93c40a660b6cdf74
From: Thomas Munro
Sent: Tues
On Sat, Sep 5, 2020 at 2:34 AM Alvaro Herrera wrote:
> On 2020-Sep-04, Jakub Wartak wrote:
> > After removing HASH_FFACTOR PostgreSQL still compiles... Would
> > removing it break some external API/extensions ?
>
> FWIW, HASH_FFACTOR has *never* been used in Postgres core code.
>
> https://postgr
On 2020-Sep-04, Jakub Wartak wrote:
> After removing HASH_FFACTOR PostgreSQL still compiles... Would
> removing it break some external API/extensions ?
FWIW, HASH_FFACTOR has *never* been used in Postgres core code.
https://postgr.es/m/20160418180711.55ac82c0@fujitsu already reported
that this
On Fri, Sep 04, 2020 at 07:01:41AM +, Jakub Wartak wrote:
Greetins hackers,
I have mixed feelings if this welcome contribution as the potential
gain is relatively small in my tests, but still I would like to point
out that HASH_FFACTOR functionality from dynahash.c could be removed or
optim
Greetins hackers,
I have mixed feelings if this welcome contribution as the potential gain is
relatively small in my tests, but still I would like to point out that
HASH_FFACTOR functionality from dynahash.c could be removed or optimized
(default fill factor is always 1, there's not a single p
12 matches
Mail list logo
