| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, "Marc Mamin" <M(dot)Mamin(at)intershop(dot)de> |
| Subject: | Re: Qual evaluation cost estimates for GIN indexes |
| Date: | 2012-02-16 23:30:53 |
| Message-ID: | 293.1329435053@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-02-16 23:42:15 | Re: Designing an extension for feature-space similarity search |
| Previous Message | Tom Lane | 2012-02-16 23:15:25 | Qual evaluation cost estimates for GIN indexes |