Re: Patch for fast gin cache performance improvement

Looks like my community login is still not working. No rush, just wanted to
let you know. Thanks!

Ian

On Tue, Jun 18, 2013 at 11:41 AM, Ian Link <ian(at)ilink(dot)io> wrote:

>
> No worries! I'll just wait until it's up again.
> Thanks
> Ian
>
> Kevin Grittner <kgrittn(at)ymail(dot)com>
> Tuesday, June 18, 2013 9:15 AM
>
> Oops -- we seem to have a problem with new community logins at the
> moment, which will hopefully be straightened out soon. You might
> want to wait a few days if you don't already have a login.
>
> --
> Kevin Grittner
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
> Kevin Grittner <kgrittn(at)ymail(dot)com>
> Tuesday, June 18, 2013 9:09 AM
>
> Ian Link <ian(at)ilink(dot)io> <ian(at)ilink(dot)io> wrote:
>
>
> This patch contains a performance improvement for the fast gin
> cache.
>
> Our test queries improve from about 0.9 ms to 0.030 ms.
>
> Impressive!
>
>
> Thanks for reading and considering this patch!
>
>
> Congratulations on your first PostgreSQL patch! To get it
> scheduled for review, please add it to this page:
> https://commitfest.postgresql.org/action/commitfest_view/open
>
>
> You will need to get a community login (if you don't already have
> one), but that is a quick and painless process. Choose an
> appropriate topic (like "Performance") and reference the message ID
> of the email to which you attached the patch. Don't worry about
> the fields for reviewers, committer, or date closed.
>
> Sorry for the administrative overhead, but without it things can
> fall through the cracks. You can find an overview of the review
> process with links to more detail here:
>
> http://wiki.postgresql.org/wiki/CommitFest
>
> Thanks for contributing!
>
>
> Ian Link <ian(at)ilink(dot)io>
> Monday, June 17, 2013 9:42 PM
> *
>
> This patch contains a performance improvement for the fast gin cache. As
> you may know, the performance of the fast gin cache decreases with its
> size. Currently, the size of the fast gin cache is tied to work_mem. The
> size of work_mem can often be quite high. The large size of work_mem is
> inappropriate for the fast gin cache size. Therefore, we created a separate
> cache size called gin_fast_limit. This global variable controls the size of
> the fast gin cache, independently of work_mem. Currently, the default
> gin_fast_limit is set to 128kB. However, that value could need tweaking.
> 64kB may work better, but it's hard to say with only my single machine to
> test on.
>
> On my machine, this patch results in a nice speed up. Our test queries
> improve from about 0.9 ms to 0.030 ms. Please feel free to use the test
> case yourself: it should be attached. I can look into additional test cases
> (tsvectors) if anyone is interested.
>
> In addition to the global limit, we have provided a per-index limit:
> fast_cache_size. This per-index limit begins at -1, which means that it is
> disabled. If the user does not specify a per-index limit, the index will
> simply use the global limit.
>
> I would like to thank Andrew Gierth for all his help on this patch. As
> this is my first patch he was extremely helpful. The idea for this
> performance improvement was entirely his. I just did the implementation.
> Thanks for reading and considering this patch!*
>
>
> Ian Link
>
>