"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> - tbm_add_tuples(tbm, &scan->xs_ctup.t_self, 1, false);
> + tbm_add_tuples(tbm, &scan->xs_ctup.t_self, 1, true);
Hah, I bet that explains Jonah's complaint that recheck didn't seem to
be happening in his tests.
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> On Fri, Sep 5, 2008 at 2:21 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
>> Ok now that I made it so it actually *test* collisions, with the patch
>> it always returns all rows that matched the hashed "key".
> And here is the fix, we just forget to set
Abhijit Menon-Sen wrote:
> I thought -patches was supposed to die. What happened?
I was wondering the same thing. Peter?
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ
On Fri, Aug 29, 2008 at 7:39 PM, Brendan Jurd <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Well, it's been a long time coming, but I've finally got a patch to
> improve the error handling of to_date() and to_timestamp(), as
> previously discussed on -hackers. [1][2]
BTW -patches is obsolete just submi
On Sun, Aug 31, 2008 at 3:35 PM, Ryan Bradetich <[EMAIL PROTECTED]> wrote:
> Hello all,
>
a few comments.
- i think you have to add some more comments in uint.c file and maybe
a header indicating this is part of the postgresql project or that is
intended to use with postgres or something of the l
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> seems there is something wrong in the unlikely macro (i'm using GCC
> 4.2.3 in Ubuntu 4.2.3-2ubuntu7 with amd64)
> postgres=# select -256::uint1;
> ERROR: uint1 out of range
No, that's just because this is parsed as -(256::uint1)
"David Rowley" <[EMAIL PROTECTED]> writes:
> I've made and attached the changes Heikki recommended.
I looked this over a bit and was immediately confused by one thing:
the introductory comment says that the skip table size ought to be based
on the length of the haystack, which makes sense to me, b
I wrote:
> I looked this over a bit and was immediately confused by one thing:
> the introductory comment says that the skip table size ought to be based
> on the length of the haystack, which makes sense to me, but the code is
> actually initializing it on the basis of len2, ie, the length of the
On Sat, Sep 6, 2008 at 3:57 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jaime Casanova" <[EMAIL PROTECTED]> writes:
>> seems there is something wrong in the unlikely macro (i'm using GCC
>> 4.2.3 in Ubuntu 4.2.3-2ubuntu7 with amd64)
>
>> postgres=# select -256::uint1;
>> ERROR: uint1 out of range
>
On Sat, Sep 6, 2008 at 3:57 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jaime Casanova" <[EMAIL PROTECTED]> writes:
>> seems there is something wrong in the unlikely macro (i'm using GCC
>> 4.2.3 in Ubuntu 4.2.3-2ubuntu7 with amd64)
>
>> postgres=# select -256::uint1;
>> ERROR: uint1 out of range
>
Tom Lane wrote:
> I looked this over a bit and was immediately confused by one thing:
> the introductory comment says that the skip table size ought to be based
> on the length of the haystack, which makes sense to me, but the code is
> actually initializing it on the basis of len2, ie, the length
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> On Sat, Sep 6, 2008 at 3:57 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> postgres=# select -256::uint1;
>>> ERROR: uint1 out of range
>>
>> No, that's just because this is parsed as -(256::uint1)
> actually, i thought that case is right but the -255:
On Sat, Sep 6, 2008 at 1:09 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>For the convenience of anyone intending to test, here is an updated
>patch against CVS HEAD that incorporates Alex's fix.
Here are the results for a table containing 1 million entries that
will generate hash collisions. It paint
2008/9/6 Alex Hunsaker <[EMAIL PROTECTED]>:
> pgbench -c1 -n -t1000 -f bench_bitmap.sql
> cvs head: tps = 24.011871
> v5: tps = 2.543123
oops forgot to attach bench_bitmap.sql
bench_bitmap.sql
Description: Binary data
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.o
On Sat, Sep 6, 2008 at 7:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Now, if (-255)::uint1 fails to throw error, that would be a bug IMHO.
> Casting any negative value to uint ought to fail, no?
>
then the patch is right but it seems to me like that is broking the
law of less surprise i expecte
"Jaime Casanova" <[EMAIL PROTECTED]> writes:
> then the patch is right but it seems to me like that is broking the
> law of less surprise i expected -2::uint1 to be equivalent to
> (-2)::uint1 that should be at least documented, no?
See the precedence table here:
http://www.postgresql.org/docs/8.3
On Sat, Sep 6, 2008 at 3:41 PM, Jaime Casanova
<[EMAIL PROTECTED]> wrote:
>
> i still have to make some more test...
>
why i need the cast in this case? even if the cast is really necesary
(the message seems realy ugly)
contrib_regression=# select * from t1 where f1 > 35;
ERROR: unsupported type
17 matches
Mail list logo
