> 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?
I think it makes sense to maintain this separation. If the user doesn't
need a per-index setting, they don't have to use the parameter. Since
the parameter is off by default, they don't even need to worry about it.
There might as well be one parameter for users that don't need
fine-grained control. We can document this and I don't think it will be
confusing to the user.
> 4. In my understanding, the small value of gin_fast_limit/fast_cache_size leads
> to the increase in GIN search performance, which, however, leads to the decrease
> in GIN update performance. Am I right? If so, I think the tradeoff should be
> noted in the documentation.
I believe this is correct.
> 5. The following documents in Chapter 57. GIN Indexes need to be
> updated: * 57.3.1. GIN Fast Update Technique * 57.4. GIN Tips and Tricks
Sure, I can add something.
> 6. I would like to see the results for the additional test cases (tsvectors).
I don't really have any good test cases for this available, and have
very limited time for postgres at the moment. Feel free to create a test
case, but I don't believe I can at the moment. Sorry!
> 7. The commented-out elog() code should be removed.
Sorry about that, I shouldn't have submitted the patch with those still
there.
I should have a new patch soonish, hopefully. Thanks for your feedback!
Ian
Ian Link wrote:
> 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.