Re: Various breakages in new contrib/isn module
От | Jeremy Kronuz |
---|---|
Тема | Re: Various breakages in new contrib/isn module |
Дата | |
Msg-id | BAY107-F325393D423BAB354C03427D8E10@phx.gbl обсуждение исходный текст |
Ответ на | Re: Various breakages in new contrib/isn module (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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/
В списке pgsql-hackers по дате отправления: