Re: Patch for fast gin cache performance improvement - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Patch for fast gin cache performance improvement
Date
Msg-id 004001cebb63$669f85d0$33de9170$@lab.ntt.co.jp
Whole thread Raw
In response to Re: Patch for fast gin cache performance improvement  ("Etsuro Fujita" <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: Patch for fast gin cache performance improvement
List pgsql-hackers
I wrote:
> I had a look over this patch.  I think this patch is interesting and very
useful.
> Here are my review points:

> 8. I think there are no issues in this patch.  However, I have one question:
> how this patch works in the case where gin_fast_limit/fast_cache_size = 0?  In
> this case, in my understanding, this patch inserts new entries into the
pending
> list temporarily and immediately moves them to the main GIN data structure
using
> ginInsertCleanup().  Am I right?  If so, that is obviously inefficient.

Sorry, There are incorrect expressions.  I mean gin_fast_limit > 0 and
fast_cache_size = 0.

Although I asked this question, I've reconsidered about these parameters, and it
seems that these parameters not only make code rather complex but are a little
confusing to users.  So I'd like to propose to introduce only one parameter:
fast_cache_size.  While users that give weight to update performance for the
fast update technique set this parameter to a large value, users that give
weight not only to update performance but to search performance set this
parameter to a small value.  What do you think about this?

Thanks,

Best regards,
Etsuro Fujita





pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Wait free LW_SHARED acquisition
Next
From: Rushabh Lathia
Date:
Subject: Re: insert throw error when year field len > 4 for timestamptz datatype