| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Lillian Berry <lillian(at)star-ark(dot)net>, pgsql-performance(at)lists(dot)postgresql(dot)org, infra(at)pluralkit(dot)me |
| Subject: | Re: Slow queries on simple index |
| Date: | 2026-01-18 09:24:56 |
| Message-ID: | 8f2a034a-6e32-43f4-92e9-276b15dc0a5f@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 17/1/26 22:10, Tom Lane wrote:
> Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
>> Hmm, where is the evidence that your query uses theindex? Maybe the
>> generic plan accidentally forces SeqScan?
>
> Oh ... you're on to something. I think we all assumed that this was
> an intermittent problem, but if it happens every time, I bet it's a
> datatype mismatch issue.
Yes, index mismatches due to type differences are frequently a pain for
me in the world of auto-generated queries. Why not spend a few
additional cycles to check whether a potential cast is possible?
I didn't track what happened in this example, but it would be beneficial
to let an extension implement such functionality. The prosupport
machinery attached to an index looks like a promising approach.
--
regards, Andrei Lepikhov,
pgEdge
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrei Lepikhov | 2026-01-24 22:12:54 | Re: small database huge planning time |
| Previous Message | Lillian Berry | 2026-01-17 22:06:39 | [Solved] Slow queries on simple index |