From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Prefix operator for text and spgist support |
Date: | 2018-03-23 08:45:33 |
Message-ID: | CAPpHfduzc_6G0yqJfji7NxfJ6ML5nODDx6+A15GNis5zgRho+Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 22, 2018 at 7:09 PM, Teodor Sigaev <teodor(at)sigaev(dot)ru> wrote:
> Patch looks resonable, but I see some place to improvement:
> spg_text_leaf_consistent() only needs to check with text_startswith() if
> reconstucted value came to leaf consistent is shorter than given prefix.
> For example, if level >= length of prefix then we guarantee that fully
> reconstracted is matched too. But do not miss that you may need to return
> value for index only scan, consult returnData field
>
> In attachment rebased and minorly edited version of your patch.
I took a look at this patch. In addition to Teodor's comments I can note
following.
* This line looks strange for me.
- if (strategy > 10)
+ if (strategy > 10 && strategy != RTPrefixStrategyNumber)
It's not because we added strategy != RTPrefixStrategyNumber condition
there.
It's because we already used magic number here and now have a mix of magic
number and macro constant in one line. Once we anyway touch this place,
could we get rid of magic numbers here?
* I'm a little concern about operator name. We're going to choose @^
operator for
prefix search without any preliminary discussion. However, personally I
don't
have better ideas :)
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2018-03-23 08:57:51 | Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation() |
Previous Message | Pavan Deolasee | 2018-03-23 08:35:55 | Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation() |