On Thu, Sep 4, 2008 at 9:48 PM, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
> (obviously on a 64 bit machine)
> int main(void)
> {
>unsigned long y = 0;
>unsigned cnt = 0;
>
>printf("insert into test_hash (num) values ");
>
>//while(cnt != LONG_MAX/UINT_MAX)
>wh
Heikki Linnakangas wrote:
> After reading the wikipedia article on Boyer-Moore search algorithm, it
> looks to me like this patch actually implements the simpler
> Boyer-Moore-Horspool algorithm that only uses one lookup table. That's
> probably fine, as it ought to be faster on small needles an
"David Rowley" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm. B-M-H has worst case search speed O(M*N) (where M = length of
>> pattern, N = length of search string); whereas full B-M is O(N). Maybe we
>> should build the second table when M is large?
> I'll look into this. If it pays off
Tom Lane wrote:
"David Rowley" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Hmm. B-M-H has worst case search speed O(M*N) (where M = length of
pattern, N = length of search string); whereas full B-M is O(N). Maybe we
should build the second table when M is large?
I'll look into this. If it
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Also, it would be nice to use B-M(-H) for LIKE as well.
Right offhand, that seems impossible, at least in patterns with %.
Or were you thinking of trying to separate out the fixed substrings
of a pattern and search for them with BMH?
Anyway, it's n
Andrew Chernow escribió:
> !
> printfPQExpBuffer(&conn->errorMessage,
> !
> libpq_gettext("PGEventProc \"%s\" failed during PGEVT_CONNRESET event\n"),
> !
Heikki Linnakangas wrote:
> The skip table really should be constructed only once in
> text_position_start and stored in TextPositionState. That would make a
> big difference to the performance of those functions that call
> text_position_next repeatedly: replace_text, split_text and text_to_arr
Ok now that I made it so it actually *test* collisions, with the patch
it always returns all rows that matched the hashed "key". For example
(non lobotomized inthash8, I just brute forced some collisions for 0
so that anyone can try this)
create table test_hash (num int8);
insert into test_hash (
Alvaro Herrera wrote:
>Oh, BTW: don't post to pgsql-patches. It's deprecated. Use
> pgsql-hackers instead.
I thought this too until I read
http://wiki.postgresql.org/wiki/Submitting_a_Patch
Which is correct?
David.
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To m
David Rowley escribió:
> Alvaro Herrera wrote:
> >Oh, BTW: don't post to pgsql-patches. It's deprecated. Use
> > pgsql-hackers instead.
>
> I thought this too until I read
> http://wiki.postgresql.org/wiki/Submitting_a_Patch
>
> Which is correct?
I just updated that page and the developer's FA
]
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 the recheck flag for bitmap scans.
*** a/src/
11 matches
Mail list logo
