From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Materializing a sequential scan |
Date: | 2005-10-26 23:53:02 |
Message-ID: | 12708.1130370782@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Steinar H. Gunderson" <sgunderson(at)bigfoot(dot)com> writes:
> On Wed, Oct 26, 2005 at 07:06:15PM -0400, Tom Lane wrote:
>> AFAICS, subplan_is_hashable() is testing the same conditions in 7.4 and
>> HEAD, so this isn't clear. Want to step through it and see where it's
>> deciding not to hash?
> (gdb) print opid
> $3 = 2373
I don't think you're getting a correct reading for optup, but OID
2373 is timestamp = date:
regression=# select * from pg_operator where oid = 2373;
oprname | oprnamespace | oprowner | oprkind | oprcanhash | oprleft | oprright | oprresult | oprcom | oprnegate | oprlsortop | oprrsortop | oprltcmpop | oprgtcmpop | oprcode | oprrest | oprjoin
---------+--------------+----------+---------+------------+---------+----------+-----------+--------+-----------+------------+------------+------------+------------+-------------------+---------+-----------
= | 11 | 10 | b | f | 1114 | 1082 | 16 | 2347 | 2376 | 2062 | 1095 | 2371 | 2375 | timestamp_eq_date | eqsel | eqjoinsel
(1 row)
which is marked not hashable, quite correctly since the input datatypes
aren't even the same.
My recollection is that there was no such operator in 7.4; probably in
7.4 the IN ended up using timestamp = timestamp which is hashable.
What's not clear though is why you're getting that operator --- aren't
both sides of the IN of type "date"?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Steinar H. Gunderson | 2005-10-27 00:13:48 | Re: Materializing a sequential scan |
Previous Message | Sidar López Cruz | 2005-10-26 23:47:31 | performance on query |