Gregory Stark <[EMAIL PROTECTED]> writes:
> Why do we have this hash function anyways? Is hashany faster than a decent
> crc32 implementation?
Yes, significantly. Times to hash 32K bytes 10 times on a Xeon EM64T:
hash_crc(32K): 11.388755 s
hash_any_old(32K): 4.401945 s
hash_any(32K): 3.86242
"Tom Lane" <[EMAIL PROTECTED]> writes:
> No doubt that can be worked around, but does anyone wish to argue that
> this whole thing is a bad path to be headed down? We're not going to
> gain a *whole* lot of speedup from the word-wide-hashing change, and
> so maybe this type of headache isn't wort
So the proposed changes in hash_any make its hash values different
between big-endian and little-endian machines (at least for string keys;
for keys that are really arrays of int, I think the changes will
unify the behavior). This means that the hash_seq_search traversal
order for an internal hash
Shane Ambler <[EMAIL PROTECTED]> writes:
> Would this be the issue fixed in 8.1.1? -
> Prevent autovacuum from crashing during ANALYZE of expression index
More likely this one:
2007-06-14 09:53 alvherre
* src/backend/commands/: vacuum.c (REL8_1_STABLE), vacuum.c
(REL8_2_STABLE),
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Shane Ambler wrote:
>
>> Given that the analyze will obviously take a long time, is this scenario
>> likely to happen with 8.3.1? or has it been fixed since 8.1.x?
>
> In 8.3, autovacuum cancels itself if it sees it is conflicting with
> another que
Alvaro Herrera wrote:
Shane Ambler wrote:
Given that the analyze will obviously take a long time, is this scenario
likely to happen with 8.3.1? or has it been fixed since 8.1.x?
In 8.3, autovacuum cancels itself if it sees it is conflicting with
another query.
Would this be the issue fixed
Shane Ambler wrote:
> Given that the analyze will obviously take a long time, is this scenario
> likely to happen with 8.3.1? or has it been fixed since 8.1.x?
In 8.3, autovacuum cancels itself if it sees it is conflicting with
another query.
> Would this be the issue fixed in 8.1.1? -
> Preve
I am currently attempting to import the world street map data as
currently available from openstreetmap.org and am wondering if I will
come across a possible problem that is mentioned on their website, which
appears to be relevant for 8.1
From http://wiki.openstreetmap.org/index.php/Mapnik th
On Sat, 05 Apr 2008 09:18:07 +0200
PFC <[EMAIL PROTECTED]> wrote:
> But of course you need the ISP to do it for you if you are not
> superuser.
> Some will bother to run a few commands for a user, some won't...
Right. I encourage my competitors to do nothing for their clients. I
will co
Jaime Casanova wrote:
On Tue, Apr 1, 2008 at 5:40 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Apologies if this gets duplicated - original seems to have been dropped due
to patch size - this time I am sending it gzipped.
just for the record, this patch doesn't apply cleanly to CVS
On Sat, Apr 5, 2008 at 5:11 PM, Martijn van Oosterhout
<[EMAIL PROTECTED]> wrote:
> It even went so far that you could build the install/deinstall scripts
> into the module itself, so all postgres had to do was dlopen() the
> module it could access the install script. It fails due to the fact
>
On Fri, Apr 04, 2008 at 08:22:51PM -0400, Aidan Van Dyk wrote:
> Today was the first time I actually ever looked at the create function
> and create language code, and I'm actually suprised at how little
> "contract" there seems to be between a object file and the created
> function. But since it'
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> Why wouldn't you just run it against template1 so that it is available
> in every database created after that?
Well maybe you don't want *every* customer to have it or not every customer
wants it. And also, what do you do about modules you add afte
On Sat, 05 Apr 2008 02:17:10 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
I was inclined to dismiss it myself but I think the point that's come
up here
is interesting. The ISP has to not just install an RPM or type make
install in
some source tree -- but actually log into each customer's dat
On Sat, 05 Apr 2008 02:17:10 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> I was inclined to dismiss it myself but I think the point that's come up here
> is interesting. The ISP has to not just install an RPM or type make install in
> some source tree -- but actually log into each customer's da
15 matches
Mail list logo
