Re: Prefix operator for text and spgist support

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

In response to

Responses

Browse pgsql-hackers by date

  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()