From: | "Jeremy Kronuz" <kronuz(at)hotmail(dot)com> |
---|---|
To: | pgsql-hackers(at)PostgreSQL(dot)org |
Subject: | Re: Various breakages in new contrib/isn module |
Date: | 2006-11-24 19:40:27 |
Message-ID: | BAY107-F325393D423BAB354C03427D8E10@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
Tom Lane wrote:
>I tried this and found out it's got one killer disadvantage: if one
>writes something like
>
> SELECT ... WHERE isbn_column = 'isbn-constant';
>
>then the unknown-literal constant would get resolved as type EAN13
>not type ISBN, which is not what we want. The existing cases where
>we rely on implicit promotion, such as varchar vs text, don't have a
>problem here because there's no difference in the input syntax.
Even as the unknown-literal constant is resolved as type EAN13 and not a
ISBN, internally they both are the same type, so casting should be done
almost immediately and without further conversions; does it really matter
much if more than a function is called to do the casting? (an isbn_column is
actually internally the same as a EAN13, thus comparisons are done really
fast by comparing two 64 bits integers for any two types)
>It'd be worth doing something about this, because as contrib/isn now
>stands it increases the number of operators named "=" (also "<=" etc) in
>a standard installation by more than 50%. That causes a measurable
>performance degradation for parsing simple queries, whether or not they
>involve any isn datatypes, because of the cost of resolving the meaning
>of any use of "=" :-(. And we'd really need more --- the module still
>doesn't provide the complete set of cross-isn-type comparisons, meaning
>we can't mark any of them as mergejoinable. Ugh.
For sure that's a bad thing... there are just too many operators and casting
rules in the isn module, however I'm sure there should be a way to keep this
functionality and still maintain performance; I mean, I think we should
really find a way of making it work.
I also got some suggestions; one of them being to add even more casting
features such as for being able to cast from ISBN or ISSN directly to EAN13.
For example, the first one *should* work, or would be nice if it did:
=> select ean13(1421500205);
ERROR: cannot cast ISBN to EAN13 for number: "1421500205"
=> select ean13(isbn13(1421500205));
ean13
-------------------
978-1-4215-0020-1
(1 row)
I've received some very possitive feedback from the users about the isn
module:
"I just started playing around with your most excellent isn functions,
and I'm pretty impressed."
"The developers here LOOOOOVE [the isn module]! We're actually
changing our data strcutures, to use it as a primary key - now that we
can finally trust the data! It is INVALUABLE! Thanks again!"
...so I belive it's a really useful module, we must try to find a way to
improve the way operators are handled or a way to reduce the number of them
needed by the module to accomplish the same tasks.
I'll wait for your suggestions, I hope we can work this out for the better
and find a good way to increase the performance, I'll try to help in any way
I can.
Regards,
Kronuz.
"Fools rush in where fools have been before" - Unknown
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-11-24 19:48:22 | Re: RC1 blocker issues |
Previous Message | Jim Nasby | 2006-11-24 19:32:11 | Re: Allowing SYSDATE to Work |