Обсуждение: Re: pg_Restore

Adrian Klaver wrote:
> On 01/21/2013 08:46 AM, bhanu udaya wrote:

>> Can we achieve this template or pg_Restore in less than 20
>> minutes time.

> Seems to me this is where Point in Time Recovery(PITR) might be
> helpful.

Maybe, if the source is on a different set of drives, to reduce
contention for storage and head movement. Either way it is down to
just a straight file copy, so it is the speed of your disk system
that is the limiting factor, not anything within PostgreSQL.

The more sure way of speeding it up is to add more spindles to your
drive array and make sure you are using a good RAID controller with
battery-backed cache.

-Kevin

On Mar 1, 2013, at 3:18, bhanu udaya <udayabhanu1984@hotmail.com> wrote:

> I need a query to retrieve all the n level hierarchy when a Child node_id is passed. For example; if I pass 7, then i
needparent nodes as below: I want to achive this in postgres database (version 9.2) without connect by prior. 
>
> 3   5
> 5   6
> 6  7
>
> Any reply on this is great help.

You're probably looking for recursive common table expressions:
http://www.postgresql.org/docs/9.2/static/queries-with.html

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.

On 6/18/2013 10:31 AM, bhanu udaya wrote:
> My PostgresSQL (9.2) is crashing after certain load tests. Currently,
> postgressql is crashing when simulatenously 800 to 1000 threads are
> run on a 10 million records schema. Not sure, if we have to tweak some
> more parameters of postgres. Currently, the postgressql is configured
> as below on a 7GB Ram on an Intel Xeon CPU E5507 2.27 GZ. Is this
> postgres limitation to support only 800 threads or any other
> configuration required. Please look at the log as below with errors.
> Please reply

thats an insanely high number of connections on a quad core processor.
in general, any more than 2-4X the number of cpu hardware threads in
concurrent queries is counterproductive and will result in higher
overhead and less throughput.   if you have a real world use case for
800-1000 client threads and your workload is predominately short fast
transactions ("OLTP"), you should use a connection pooler like pgbouncer
and limit the number of active connections to something like 32 on your
4 core/8 thread CPU.



--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

On 18/06/13 18:31, bhanu udaya wrote:
> Hello,
> Greetings.
>
> My PostgresSQL (9.2) is crashing after certain load tests. Currently,
> postgressql is crashing when simulatenously 800 to 1000 threads are run
> on a 10 million records schema. Not sure, if we have to tweak some more
> parameters of postgres. Currently, the postgressql is configured as
> below on a 7GB Ram on an Intel Xeon CPU E5507 2.27 GZ. Is this postgres
> limitation to support only 800 threads or any other configuration
> required. Please look at the log as below with errors. Please reply
>
>
> max_connections    5000
> shared_buffers    2024 MB
> synchronous_commit     off
> wal_buffers     100 MB
> wal_writer_delays     1000ms
> checkpoint_segments     512
> checkpoint_timeout     5 min
> checkpoint_completion_target     0.5
> checkpoint_warning     30s
> work_memory     1G
> effective_cache_size     5 GB

Just to point out, your memory settings are set to allow *at least*

  shared-buffers 2GB + (5000 * 1GB) = 5TB+

You don't have that much memory. You probably don't have that much disk.
This is never going to work.

As has been said, there's no way you can do useful work simultaneously
with 1000 threads if you only have 4 cores - use a connection pooler.
You'll also need to reduce work_mem to 1MB or so.

--
   Richard Huxton
   Archonet Ltd

On Thu, Jun 20, 2013 at 5:17 AM, Richard Huxton <dev@archonet.com> wrote:
> On 18/06/13 18:31, bhanu udaya wrote:
>>
>> Hello,
>> Greetings.
>>
>> My PostgresSQL (9.2) is crashing after certain load tests. Currently,
>> postgressql is crashing when simulatenously 800 to 1000 threads are run
>> on a 10 million records schema. Not sure, if we have to tweak some more
>> parameters of postgres. Currently, the postgressql is configured as
>> below on a 7GB Ram on an Intel Xeon CPU E5507 2.27 GZ. Is this postgres
>> limitation to support only 800 threads or any other configuration
>> required. Please look at the log as below with errors. Please reply
>>
>>
>> max_connections 5000
>> shared_buffers  2024 MB
>> synchronous_commit      off
>> wal_buffers     100 MB
>> wal_writer_delays       1000ms
>> checkpoint_segments     512
>> checkpoint_timeout      5 min
>> checkpoint_completion_target    0.5
>> checkpoint_warning      30s
>> work_memory     1G
>> effective_cache_size    5 GB
>
>
> Just to point out, your memory settings are set to allow *at least*
>
>  shared-buffers 2GB + (5000 * 1GB) = 5TB+
>
> You don't have that much memory. You probably don't have that much disk.
> This is never going to work.
>
> As has been said, there's no way you can do useful work simultaneously with
> 1000 threads if you only have 4 cores - use a connection pooler. You'll also
> need to reduce work_mem to 1MB or so.

aside: if you have particular query that needs extra work_mem, you can
always temporarily raise it at run time (unlike shared buffers).

OP needs to explore use of connection pooler, in particular pgbouncer.
 Anyways none of this explains why the server is actually crashing.

merlin

On Thursday, June 20, 2013 07:52:21 AM Merlin Moncure wrote:
> OP needs to explore use of connection pooler, in particular pgbouncer.
>  Anyways none of this explains why the server is actually crashing.

It might be hitting file descriptor limits. I didn't dig into the earlier part
of this thread much, though.

Alan Hodgson <ahodgson@simkin.ca> writes:
> On Thursday, June 20, 2013 07:52:21 AM Merlin Moncure wrote:
>> OP needs to explore use of connection pooler, in particular pgbouncer.
>> Anyways none of this explains why the server is actually crashing.

> It might be hitting file descriptor limits. I didn't dig into the earlier part
> of this thread much, though.

The disturbing part of the original report was this:

>>> 2013-06-11 16:54:14 GMT [22226]: [1-1]PANIC:  stuck spinlock (0x2aaab54279d4) detected at bufmgr.c:1239

which implies that something was holding a buffer header spinlock for an
unreasonably long time (roughly 2 minutes, when no operation that holds
such a lock should take more than a few nanoseconds).  But if you were
running a load test that absolutely mashed the machine into the ground,
as the OP seems to have been doing, maybe that could happen --- perhaps
some unlucky backend got interrupted and then swapped out during the
narrow window where it held such a lock, and the machine was too
overloaded to give that process any more cycles for a very long time.

As has been noted already, this test setup seems to have overloaded the
machine by at least two orders of magnitude compared to useful settings
for the available hardware.  The "stuck spinlock" error would only come
out if a lock had been held for quite a lot more than two orders of
magnitude more time than expected, though.  So I'm not entirely sure
that I buy this theory; but it's hard to see another one.  (I discount
the obvious other theory that there's a software bug, because I just
looked through 9.2's bufmgr.c very carefully, and there are no code
paths where it fails to release a buffer header lock within a very few
instructions from where it took the lock.)

            regards, tom lane

bhanu udaya wrote:
> What is the best way of doing case insensitive searches in postgres using Like.

      Table "laurenz.t"
 Column |  Type   | Modifiers
--------+---------+-----------
 id     | integer | not null
 val    | text    | not null
Indexes:
    "t_pkey" PRIMARY KEY, btree (id)


CREATE INDEX t_val_ci_ind ON t ((upper(val) text_pattern_ops);

ANALYZE t;

EXPLAIN SELECT id FROM t WHERE upper(val) LIKE 'AB%';

                                  QUERY PLAN
------------------------------------------------------------------------------
 Index Scan using t_val_ci_ind on t  (cost=0.01..8.28 rows=1 width=4)
   Index Cond: ((upper(val) ~>=~ 'AB'::text) AND (upper(val) ~<~ 'AC'::text))
   Filter: (upper(val) ~~ 'AB%'::text)
(3 rows)

Yours,
Laurenz Albe

On 6/28/2013 6:59 PM, bhanu udaya wrote:
> select * from table where type like 'ab%'. It should get all above 3
> records.  Is there a way the database itself can be made
> case-insensitive with UTF8 characterset. I tried with character type &
> collation POSIX, but it did not really help.

use ILIKE



--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

On Jun 29, 2013, at 3:59, bhanu udaya <udayabhanu1984@hotmail.com> wrote:

> Thanks. But, I do not want to convert into upper and show the result.

Why not? It won't modify your results, just the search condition:

SELECT id, val FROM t WHERE upper(val) LIKE 'AB%' ORDER BY val;

Or:

SELECT id, val FROM t WHERE upper(val) LIKE 'AB%' ORDER BY upper(val), val;


> Example, if I have records as below:
> id  type
> 1. abcd
> 2. Abcdef
> 3. ABcdefg
> 4. aaadf
>
> The below query should report all the above
>
> select * from table where type like 'ab%'. It should get all above 3 records.  Is there a way the database itself can
bemade case-insensitive with UTF8 characterset. I tried with character type & collation POSIX, but it did not really
help.

I was under the impression this would work, but ISTR that not every OS has this capability (Postgres makes use of the
OScollation mechanics). So, what OS are you running the server on? 

> > From: laurenz.albe@wien.gv.at
> > To: udayabhanu1984@hotmail.com; pgsql-general@postgresql.org
> > Subject: RE: Postgres case insensitive searches
> > Date: Fri, 28 Jun 2013 12:32:00 +0000

Please do not top-post on this list.

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.

On Jun 29, 2013, at 15:02, bhanu udaya <udayabhanu1984@hotmail.com> wrote:

> I agree that it is just search condition. But, in a 2.5 million record table search, upper function is not that fast.
 

Suit yourself, the solution is there.

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.

On 06/29/2013 09:02 AM, bhanu udaya wrote:<br /><blockquote cite="mid:COL127-W1529DEA2A427BDB5A28C9FD3770@phx.gbl"
type="cite"><style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style><div dir="ltr">Hello,<br /> I agree that it is just search condition. But, in a 2.5 million record table
search,upper function is not that fast.  The expectation is to get the query retrieved in 100 ms...with all indexes
used.<br/>  <br /> I tried with upper, Citext, but the result set was more than a second.<br />  <br /> The OS server
weare using is Linux 64 bit.<br />  <br /> Thanks and Regards<br /> Radha Krishna<br />  <br /><div>> Subject: Re:
[pgadmin-support][GENERAL] Postgres case insensitive searches<br /> > From: <a class="moz-txt-link-abbreviated"
href="mailto:haramrae@gmail.com">haramrae@gmail.com</a><br/> > Date: Sat, 29 Jun 2013 09:37:51 +0200<br /> > CC:
<aclass="moz-txt-link-abbreviated" href="mailto:laurenz.albe@wien.gv.at">laurenz.albe@wien.gv.at</a>; <a
class="moz-txt-link-abbreviated"href="mailto:pgsql-general@postgresql.org">pgsql-general@postgresql.org</a>; <a
class="moz-txt-link-abbreviated"href="mailto:pgadmin-support@postgresql.org">pgadmin-support@postgresql.org</a><br />
>To: <a class="moz-txt-link-abbreviated" href="mailto:udayabhanu1984@hotmail.com">udayabhanu1984@hotmail.com</a><br
/>> <br /> > On Jun 29, 2013, at 3:59, bhanu udaya <a class="moz-txt-link-rfc2396E"
href="mailto:udayabhanu1984@hotmail.com"><udayabhanu1984@hotmail.com></a>wrote:<br /> > <br /> > >
Thanks.But, I do not want to convert into upper and show the result. <br /> > <br /> > Why not? It won't modify
yourresults, just the search condition:<br /> > <br /> > SELECT id, val FROM t WHERE upper(val) LIKE 'AB%' ORDER
BYval;<br /> > <br /> > Or:<br /> > <br /> > SELECT id, val FROM t WHERE upper(val) LIKE 'AB%' ORDER BY
upper(val),val;<br /> > <br /> > <br /> > > Example, if I have records as below:<br /> > > id type<br
/>> > 1. abcd<br /> > > 2. Abcdef<br /> > > 3. ABcdefg<br /> > > 4. aaadf<br /> > > <br
/>> > The below query should report all the above <br /> > > <br /> > > select * from table where
typelike 'ab%'. It should get all above 3 records. Is there a way the database itself can be made case-insensitive with
UTF8characterset. I tried with character type & collation POSIX, but it did not really help.<br /> > <br /> >
Iwas under the impression this would work, but ISTR that not every OS has this capability (Postgres makes use of the OS
collationmechanics). So, what OS are you running the server on?<br /> > <br /></div></div></blockquote><br />
Duplicatethe column with an upper or lowercase version and run all queries against that.<br /><br /> CREATE TABLE foo
(<br/>     id serial PRIMARY KEY,<br />     val text,<br />     val_lower text<br /> );<br /><br /> Index val_lower.
Usetriggers to keep val and val_lower in sync and discard all attempts to write directly to val_lower. Then all queries
wouldbe of the form<br /><br /> SELECT id, val<br /> FROM foo<br /> WHERE val_lower LIKE 'ab%';<br /><br /> Wouldn't
wantto write every table like this, but if (a) query speed trumps all other requirements and (b) functional index,
CITEXT,etc. have all been rejected as not fast enough…<br /><br /> --Lee<br /><br /><br /><pre class="moz-signature"
cols="72">--
 
Lee Hachadoorian
Assistant Professor in Geography, Dartmouth College
<a class="moz-txt-link-freetext" href="http://freecity.commons.gc.cuny.edu">http://freecity.commons.gc.cuny.edu</a>
</pre>

On 06/28/2013 03:21 AM, bhanu udaya wrote:
> Hello,
>
> Grettings,
>
> What is the best way of doing case insensitive searches in postgres
> using Like.
>
> Ilike - does not use indexes
> function based indexes are not as fast as required.
> CITEXT - it still taking 600 ms - 1 second on a 2.2 million rows... does
> not use index
> Collation Indexes creation with POSIX - does not really work.
> GIST/GIN indexes are faster when using like, but not case insenstive.
>
> Is there a better way of resolving this case insenstive searches with
> fast retrieval.

O.k. there is not anywhere near enough information here to provide you
with a proper answer but here are the two things you should look at:

CITEXT: You said it takes 600ms - 1 second. Is that a first run or is
the relation cached? Second how do you know it isn't using the index?
Have you ran an explain analyze? In order for CITEXT to use an index it
the value being searched must be the PRIMARY KEY, is your column the
primary key?

Second, you have provided us with zero information on your hardware
configuration. 2.2 million rows is a low of rows to seqscan, if they
aren't cached or if you don't have reasonable hardware it is going to
take time no matter what you do.

Third, have you tried this with unlogged tables (for performance)?

Fourth, there was another person that suggested using UPPER() that is a
reasonable suggestion. The docs clearly suggest using lower(), I don't
actually know if there is a difference but that is the common way to do
it and it will use an index IF you make a functional index on the column
using lower.

JD




>
> Thanks and Regards
> Radha Krishna
>


--
Command Prompt, Inc. - http://www.commandprompt.com/  509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
For my dreams of your image that blossoms
    a rose in the deeps of my heart. - W.B. Yeats

On 6/29/2013 9:24 AM, bhanu udaya wrote:
> Upper and Lower functions are not right choice when the table is > 2.5
> million and where we also have heavy insert transactions.
>
> I doubt, if we can cache the table if there are frequent
> inserts/updates.  The good idea would be to get the DB to case
> insenstive configuration like SQL Server. I would go for this
> solution, if postgres supports.

you need an INDEX on lower(field) or upper(field).   this is only
computed when values are inserted.

if you like a specific feature of SQL Server, then by all means, use SQL
Server.   postgres does not and will not support automatic case
insensitive data.

--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

On 06/29/2013 09:24 AM, bhanu udaya wrote:

> Upper and Lower functions are not right choice when the table is > 2.5
> million and where we also have heavy insert transactions.

Prove it. Seriously, just run a test case against it. See how it works
for you. Inserts are generally a very inexpensive operation with Postgres.

>
> I doubt, if we can cache the table if there are frequent
> inserts/updates.  The good idea would be to get the DB to case
> insenstive configuration like SQL Server. I would go for this solution,
> if postgres supports.

Postgres does not.

And as Jon said, maybe Postgres isn't the right solution for you. That
would be a bummer but we can't be all things to all people.


JD

--
Command Prompt, Inc. - http://www.commandprompt.com/  509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
For my dreams of your image that blossoms
    a rose in the deeps of my heart. - W.B. Yeats

On Jun 30, 2013 7:07 PM, "bhanu udaya" <udayabhanu1984@hotmail.com> wrote:
>
>
> I almost used every option ; upper, posix, gist, gin, citext, etc. feature of the postgres to get the query most optimal.. If a particular query is taking  1 + second for one user/thread, then for many users accessing it concurrently would take lot of resources and the performance would be dropped in no time may be for 10 users .. I am trying to  get the best way of achieving things with postgres.
>  
>  I do not know what else can be done to get the performance more optimal. if there are any good suggestions in tweaking db parameters or with some index that can help, then  I would love to experiment it and achieve it.
>  
> We have observed that inserts are ok, but the selects are dropping performance and not acceptable.  Show me an index that can retrieve a simple select query (case insensitive) in 100 -200 ms.  from a table which has 2- 10 million records.  Is this possible ? I could have gone for partitions, etc., but it is plan B and more over partitions in postgres has to undergo more manual process.
>

How many rows are in the result? Can you use a partial index? What's the usage pattern? Can you cache the result in a materialized view?

In general, getting one row from an index from a table that fits in your RAM is possible in a few ms. Case insensitive or not.

Can you show us a explain analyze.

>  
> Thanks for all replies and help.
> ________________________________
> Subject: Re: [GENERAL] Postgres case insensitive searches
> From: neilt@neiltiffin.com
> Date: Sat, 29 Jun 2013 14:08:47 -0500
> CC: pgsql-general@postgresql.org
> To: udayabhanu1984@hotmail.com
>
>
> On Jun 29, 2013, at 11:24 AM, bhanu udaya <udayabhanu1984@hotmail.com> wrote:
>
>> Upper and Lower functions are not right choice when the table is > 2.5 million and where we also have heavy insert transactions.
>
>
> PostgreSQL and SQL Server are completely different.  Rules that apply to SQL Server do not necessarily apply to PostgreSQL.
>
> You problem is not the use of upper() or lower() it is the assumption what works in SQL Server is the best way to use PostgreSQL.  You'll get farther if you benchmark several of the suggestions, then if the performance is not good enough, ask how to improve the performance.  This will take a little work on your part, but that is how you learn.
>
> Neil

bhanu udaya wrote:
>>> What is the best way of doing case insensitive searches in postgres using Like.
>>
>> Table "laurenz.t"
>> Column | Type | Modifiers
>> --------+---------+-----------
>> id | integer | not null
>> val | text | not null
>> Indexes:
>> "t_pkey" PRIMARY KEY, btree (id)
>>
>>
>> CREATE INDEX t_val_ci_ind ON t ((upper(val) text_pattern_ops);
>>
>> ANALYZE t;
>>
>> EXPLAIN SELECT id FROM t WHERE upper(val) LIKE 'AB%';
>>
>> QUERY PLAN
>> ------------------------------------------------------------------------------
>> Index Scan using t_val_ci_ind on t (cost=0.01..8.28 rows=1 width=4)
>> Index Cond: ((upper(val) ~>=~ 'AB'::text) AND (upper(val) ~<~ 'AC'::text))
>> Filter: (upper(val) ~~ 'AB%'::text)
>> (3 rows)

> Thanks. But, I do not want to convert into upper and show the result.
> Example, if I have records as below:
> id  type
> 1. abcd
> 2. Abcdef
> 3. ABcdefg
> 4. aaadf
> 
> The below query should report all the above

No, it shouldn't :^)

> select * from table where type like 'ab%'. It should get all above 3 records.  Is there a way the
> database itself can be made case-insensitive with UTF8 characterset. I tried with character type &
> collation POSIX, but it did not really help.

My solution is fast and efficient, it will call upper() only once
per query.  I don't see your problem.  Different database systems
do things in different ways, but as long as you can do what you need
to do, that should be good enough.

Yours,
Laurenz Albe

On Mon, Jul 1, 2013 at 10:01 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
> bhanu udaya wrote:
>>>> What is the best way of doing case insensitive searches in postgres using Like.
>>>
>>> Table "laurenz.t"
>>> Column | Type | Modifiers
>>> --------+---------+-----------
>>> id | integer | not null
>>> val | text | not null
>>> Indexes:
>>> "t_pkey" PRIMARY KEY, btree (id)
>>>
>>>
>>> CREATE INDEX t_val_ci_ind ON t ((upper(val) text_pattern_ops);
>>>
>>> ANALYZE t;
>>>
>>> EXPLAIN SELECT id FROM t WHERE upper(val) LIKE 'AB%';
>>>
>>> QUERY PLAN
>>> ------------------------------------------------------------------------------
>>> Index Scan using t_val_ci_ind on t (cost=0.01..8.28 rows=1 width=4)
>>> Index Cond: ((upper(val) ~>=~ 'AB'::text) AND (upper(val) ~<~ 'AC'::text))
>>> Filter: (upper(val) ~~ 'AB%'::text)
>>> (3 rows)
>

>
> My solution is fast and efficient, it will call upper() only once
> per query.  I don't see your problem.  Different database systems
> do things in different ways, but as long as you can do what you need
> to do, that should be good enough.
>
> Yours,
> Laurenz Albe
>

I was toying around a little bit with this example, just for my
understanding, the function upper is called for every row in the
result. I think this has something to to with the filter in the plan.
This is what I did

create table foo as (select md5(random()::text) from
generate_series(1,2.5e6::integer));
-- create a little wrapper function to see when it is called
create ': create or replace function test_upper(text_in TEXT) RETURNS TEXT AS
$func$
begin
    raise warning 'called';
    return upper(text_in);
end;
$func$ LANGUAGE plpgsql IMMUTABLE;

create index foo_ind on foo (test_upper(md5) text_pattern_ops); --lots
of 'called' ouptut
analyze foo;

-- here you see that the function is called for every row in the result
postgres=#  select * from foo where test_upper(md5) like  'ABAAB%';
WARNING:  called
WARNING:  called
WARNING:  called
               md5
----------------------------------
 abaab10ff1690418d69c360d2dc9c8fc
 abaab339fb14a7a10324f6007d35599a
 abaab34f0cebabee89fa222bfee7b6ea
(3 rows)


postgres=# explain select * from foo where test_upper(md5) like  'ABAAB%';
                                          QUERY PLAN
----------------------------------------------------------------------------------------------
 Index Scan using foo_ind on foo  (cost=0.50..14.02 rows=250 width=33)
   Index Cond: ((test_upper(md5) ~>=~ 'ABAAB'::text) AND
(test_upper(md5) ~<~ 'ABAAC'::text))
   Filter: (test_upper(md5) ~~ 'ABAAB%'::text)
(3 rows)


So under my assumption that it is the filter that causes the function
execution, I don't understand
how a row can satisfy

--which I read as >= 'ABAAB' and < 'ABAAC'
((test_upper(md5) ~>=~ 'ABAAB'::text) AND (test_upper(md5) ~<~ 'ABAAC'::text))

and not

(test_upper(md5) ~~ 'ABAAB%'::text)


Ingmar

Ingmar Brouns wrote:
>> My solution is fast and efficient, it will call upper() only once
>> per query.  I don't see your problem.  Different database systems
>> do things in different ways, but as long as you can do what you need
>> to do, that should be good enough.

> I was toying around a little bit with this example, just for my
> understanding, the function upper is called for every row in the
> result. I think this has something to to with the filter in the plan.

You are right, and the function is also called once per
result row.  The point I was really trying to make is that
it is *not* called once per row in the table.

> postgres=# explain select * from foo where test_upper(md5) like  'ABAAB%';
>                                           QUERY PLAN
> ----------------------------------------------------------------------------------------------
>  Index Scan using foo_ind on foo  (cost=0.50..14.02 rows=250 width=33)
>    Index Cond: ((test_upper(md5) ~>=~ 'ABAAB'::text) AND
> (test_upper(md5) ~<~ 'ABAAC'::text))
>    Filter: (test_upper(md5) ~~ 'ABAAB%'::text)
> (3 rows)
> 
> 
> So under my assumption that it is the filter that causes the function
> execution, I don't understand
> how a row can satisfy
> 
> --which I read as >= 'ABAAB' and < 'ABAAC'
> ((test_upper(md5) ~>=~ 'ABAAB'::text) AND (test_upper(md5) ~<~ 'ABAAC'::text))
> 
> and not
> 
> (test_upper(md5) ~~ 'ABAAB%'::text)

I don't know, but I suspect it has to do with collations.

Yours,
Laurenz Albe