| From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
|---|---|
| To: | Brett McCormick <brett(at)web0(dot)speakeasy(dot)org> |
| Cc: | pgsql-hackers(at)hub(dot)org |
| Subject: | Re: [HACKERS] seq scan only when function not in subquery (bug?) |
| Date: | 1998-06-16 02:32:39 |
| Message-ID: | 3585D947.33E5C313@krs.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Brett McCormick wrote:
>
> sas=> explain update user set usrid = 'aaaaaaaa'
> where usrseqid=usrseqid('zlb');
>
> NOTICE: QUERY PLAN:
>
> Seq Scan on user (cost=344.07 size=658 width=154)
...
> as you can see, it uses the index when the RHS of the comparison
> in the where clause is a subquery, but a sequential scan when it
> isn't. is this a bug?
Yes, and very old :)
This is from my recent posting:
---
Another issue - handling of functions with constant args
in queries - for query
select * from T where A = upper ('bbb')
function upper ('bbb') will be executed for each tuple in T!
More of that - if there is index on T(A) then this index will
not be used for this query!
Obviously, upper ('bbb') should be executed (by Executor, not
parser/planner) once: new Param type (PARAM_EXEC) implemented
for subselects could help here too...
---
Actually, this is easy to fix...
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 1998-06-16 02:37:13 | Re: [HACKERS] Bug or Short between my brain and the keyboard? |
| Previous Message | Brett McCormick | 1998-06-15 23:44:31 | seq scan only when function not in subquery (bug?) |