I wrote:
> BTW, an entirely different line of thought is "why on earth is @@ so
> frickin expensive, when it's comparing already-processed tsvectors
> with only a few entries to an already-processed tsquery with only one
> entry??". This test case suggests to me that there's something
> unnecessarily slow in there, and a bit of micro-optimization effort
> might be well repaid.
Oh, scratch that: a bit of oprofiling shows that while the tsvectors
aren't all that long, they are long enough to get compressed, and most
of the runtime is going into pglz_decompress not @@ itself. So this
goes back to the known issue that the planner ought to try to account
for detoasting costs.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
