Hello Tom,
On Wed, Jul 30, 2008 at 7:50 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Dunno, I forget what the conclusion was about implicit casting for the
> unsigned types in your proposal. Have you experimented with seeing
> whether, eg, UNION'ing an unsigned with some signed-integer value
> behaves sensibly?
That was not one of my tests, but I will add it :)
Here are the performance tests I am planning / working on:
1. Loading of both integer and unsigned integers into a table. This test is
mainly a sanity check to ensure the unsigned integers do not add
significant time during inserts. In a perfect world, I believe they should
take the same time when the unsigned integers and integers have equal
widths. Experimentation is showing the unsigned integer to take slightly
longer. I suspect this is due to the additional integer->unsigned
integer cast? I am still digging into this for my personal curiosity.
2. Testing the < operator. The unsigned integer type provides a native cast
for the < operator.
3. Testing the & operator. The unsigned integer type does not provide a
native cast for the & operator, so they are cast up to the next larger size.
I am testing this for both signed and unsigned integers with data sets of the
following sizes: 100, 1000, 10000, 100000, 500000, 1M, 5M, and 10M rows.
I am planning to test on both 32-bit and 64-bit x86 platforms. If there is
interest, I can also run these tests on 32-bit and 64-bit PowerPC platforms.
I will add the union test to my test plan. Anything else I should add or any
holes I am missing with this test plan?
> The thread I mention above was a year or so back and was originated by
> someone who wanted to duplicate mysql's behavior. Your proposal is
> a lot more limited and might not really need to try to put the unsigned
> types into the numeric category.
Ah, ok. I will not worry about it for now.
Thanks!
- Ryan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
