Re: Allow multi-byte characters as escape in SIMILAR TO and SUBSTRING

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow multi-byte characters as escape in SIMILAR TO and SUBSTRING
Date: 2014-08-25 15:29:12
Message-ID: 53FB5648.7090806@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08/25/2014 06:14 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
>> On 08/25/2014 04:48 PM, Tom Lane wrote:
>>> [ scratches head... ] Surely similar_escape is marked immutable, and
>>> will therefore be executed exactly once in either of these formulations,
>>> because the planner will fold the expression to a constant.
>
>> Yeah, just noticed that myself..
>
> ... although, given that, it is also fair to wonder how much the speed of
> similar_escape really matters. Surely in most use-cases the pattern and
> escape char will be constants. And, when they are not, wouldn't the
> subsequent parsing work for the regexes dominate the cost of
> similar_escape anyway?
>
> IOW, I'm not sure we should be advising Jeff to duplicate code in
> order to have a fast path. Keeping it short might be the best goal.

It's certainly not worth bending over backwards for a small performance
gain here, but I think special-casing a single-byte escape sequence is
still quite reasonable. It doesn't make the code any longer.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-08-25 16:19:25 Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
Previous Message Alvaro Herrera 2014-08-25 15:17:19 Re: SKIP LOCKED DATA (work in progress)