Re: Various breakages in new contrib/isn module

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/

In response to

Browse pgsql-hackers by date

  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