| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> | 
| Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Andrus <kobruleht2(at)hot(dot)ee>, pgsql-general <pgsql-general(at)postgresql(dot)org> | 
| Subject: | Re: Query returns no rows in pg_basebackup cluster | 
| Date: | 2020-05-21 23:36:01 | 
| Message-ID: | 19749.1590104161@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Thu, May 21, 2020 at 3:57 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
> wrote:
>> Well what I was trying to figure out was:
>> "Windows server this query returns 0 rows.
>> In Windows server same query using like
>> select *  from firma1.desktop where baas like '_LOGIFAI'
>> returns properly 16 rows. "
> The LIKE query probably doesn't use an index and thus finds the relevant
> data via sequential scan and equality checks on each record.
Yeah, exactly.  An equality condition will use a btree index if
available.  LIKE, however, sees the "_" as a wildcard so it cannot
use an index and resorts to a seqscan --- which will work fine.
It's just index searches (and index-based sorts) that are broken.
Of course, if there isn't an index on the column in question
then this theory falls to the ground.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tim Cross | 2020-05-21 23:48:59 | Re: Should I use JSON? | 
| Previous Message | Adrian Klaver | 2020-05-21 23:34:22 | Re: Query returns no rows in pg_basebackup cluster |