pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedAW: [HACKERS] SELECT BUG
2+ messages / 2 participants
[nested] [flat]
* AW: [HACKERS] SELECT BUG
@ 1999-09-03 08:00 Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
0 siblings, 1 reply; 2+ messages in thread
From: Andreas Zeugswetter @ 1999-09-03 08:00 UTC (permalink / raw)
To: hackers@postgresql.org
> But if it is correct, then we need to turn off oprcanhash for bpchareq.
> Odd that no one has noticed this before.
Currently it works for constants, because they are blank padded.
It does not work for the char(8) = char(16) comparison with two
table columns.
Eighter the hash function for bpchar itself should be trailing blank
insensitive, or the bpchar would need to be padded or truncated before
computing the hash.
Andreas
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: AW: [HACKERS] SELECT BUG
@ 1999-09-03 15:20 Tom Lane <tgl@sss.pgh.pa.us>
parent: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 1999-09-03 15:20 UTC (permalink / raw)
To: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>; +Cc: hackers@postgresql.org
Andreas Zeugswetter <andreas.zeugswetter@telecom.at> writes:
>> But if it is correct, then we need to turn off oprcanhash for bpchareq.
>> Odd that no one has noticed this before.
> Currently it works for constants, because they are blank padded.
> It does not work for the char(8) = char(16) comparison with two
> table columns.
The case that can fail is equality across two different-width char
columns from different tables. If they're in the same table, or if
it's field = constant, then no join is involved so there's no risk
of hashjoin being used. So this might be a relatively rare case
after all. And I think the 6.5 optimizer is more prone to choose
hashjoin than it was in prior releases. Maybe it's not so odd that
this wasn't noticed sooner.
> Eighter the hash function for bpchar itself should be trailing blank
> insensitive, or the bpchar would need to be padded or truncated before
> computing the hash.
We don't currently have datatype-dependent hash functions; it's one-
size-fits-all. I thought a little bit about adding type-specific
hashing back when I did the last round of removing unsafe "oprcanhash"
marks, but it didn't seem worth the trouble. Unfortunately I missed
bpchareq because I didn't know it does blank stripping...
regards, tom lane
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~1999-09-03 15:20 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-09-03 08:00 AW: [HACKERS] SELECT BUG Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
1999-09-03 15:20 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox