Proposal for col LIKE $1 with generic Plan

From: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Proposal for col LIKE $1 with generic Plan
Date: 2021-03-25 02:15:36
Message-ID: CAKU4AWohsf6oFrC1cmWqEwcanaCVPTatr3oALbdCL4xt-1HW6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks to the get_index_clause_from_support, we can use index for WHERE a
like
'abc%' case. However this currently only works on custom plan. Think about
the
case where the planning takes lots of time, custom plan will not give a good
result. so I want to see if we should support this for a generic plan as
well.

The first step of this is we need to find an operator to present prefix is
just
literal. which means '%' is just '%', not match any characters. After trying
'like' and '~' operator, I find none of them can be used. for example:

PREPARE s AS SELECT * FROM t WHERE a LIKE ('^' || $1);
EXECUTE s('%abc');

'%' is still a special character to match any characters. So '~' is. So I
think
we need to define an new operator like text(a) ~^ text(b), which means a
is prefixed with b literally. For example:

'abc' ~^ 'ab` -> true
'abc' ~^ 'ab%' -> false

so the above case can be written as:

PREPARE s AS SELECT * FROM t WHERE a ~^ $1;

The second step is we need to define greater string for $1 just like
make_greater_string. Looks we have to know the exact value to make the
greater
string, so we can define a new FuncExpr like this:

Index Cond: ((md5 >= $1::text) AND (md5 < make_greater_string_fn($1)).

This may not be able to fix handle the current make_greater_string return
NULL
case. so we may define another FuncExpr like text_less_than_or_null

Index Cond: ((md5 >= $1::text) AND (text_less_than_or_null(md5,
make_greater_string_fn($1)))

Is this a right thing to do and a right method?

Thanks
--
Best Regards
Andy Fan (https://www.aliyun.com/)

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2021-03-25 02:36:38 Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
Previous Message Amit Langote 2021-03-25 01:52:25 Re: making update/delete of inheritance trees scale better