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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
