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 по дате отправления:

Предыдущее
От: Andrew Sullivan
Дата:
Сообщение: Re: Integrating Replication into Core
Следующее
От: Tom Lane
Дата:
Сообщение: Re: RC1 blocker issues