From: | Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Cc: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Speeding up GIST index creation for tsvectors |
Date: | 2020-12-15 15:04:02 |
Message-ID: | CAJ3gD9ffzHwsPGxkoK9BASg19s84YvaTxi+2yFD1LBzETL2o=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 13 Dec 2020 at 9:28 PM, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> +1
> This will make all INSERTs and UPDATES for tsvector's GiSTs.
Oh, I didn't realize that this code is getting used in GIST index
insertion and creation too. Will check there.
> Also I really like idea of taking advantage of hardware capabilities like __builtin_* etc wherever possible.
Yes. Also, the __builtin_popcount() uses SIMD vectorization (on arm64
: "cnt v0.8b, v0.8b"), hence there's all the more reason to use it.
Over and above that, I had thought that if we can auto-vectorize the
byte-by-byte xor operation and the popcount() call using compiler
optimizations, we would benefit out of this, but didn't see any more
improvement. I hoped for the benefit because that would have allowed
us to process in 128-bit chunks or 256-bit chunks, since the vector
registers are at least that long. Maybe gcc is not that smart to
translate __builtin_popcount() to 128/256 bit vectorized instruction.
But for XOR operator, it does translate to 128bit vectorized
instructions (on arm64 : "eor v2.16b, v2.16b, v18.16b")
> Meanwhile there are at least 4 incarnation of hemdistsign() functions that are quite similar. I'd propose to refactor them somehow...
Yes, I hope we get the benefit there also. Before that, I thought I
should post the first use-case to get some early comments. Thanks for
your encouraging comments :)
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-12-15 15:17:28 | Re: Proposed patch for key managment |
Previous Message | Tom Lane | 2020-12-15 14:23:41 | Re: HASH_BLOBS hazards (was Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions) |