Michael Parker <[EMAIL PROTECTED]> writes:
> sub bytea_esc {
> my ($str) = @_;
> my $buf = "";
> foreach my $char (split(//,$str)) {
> if (ord($char) == 0) { $buf .= "000"; }
> elsif (ord($char) == 39) { $buf .= "047"; }
> elsif (ord($char) == 92) { $buf .= "134"; }
>
Michael Parker <[EMAIL PROTECTED]> writes:
> The next hurdle, and I've just posted to the DBD::Pg list, is
> escaping/quoting the token strings.
If you're trying to write a bytea[] literal, I think the most reliable
way to write the individual bytes is
nnn
where nnn is *octal*. The id
Hi All,
As a SpamAssassin developer, who by my own admission has real problem
getting PostgreSQL to work well, I must thank everyone for their
feedback on this issue. Believe me when I say what is in the tree now
is a far cry from what used to be there, orders of magnitude faster
for sure. I thi
A 4xDC would be far more sensitive to poor NUMA code than 2xDC so I'm
not surprised I don't see performance issues on our 2xDC w/ < 2.6.12.
J. Andrew Rogers wrote:
On 7/30/05 12:57 AM, "William Yu" <[EMAIL PROTECTED]> wrote:
I haven't investigated the 2.6.12+ kernel updates yet -- I probably
Jim C. Nasby wrote:
On Sun, Jul 31, 2005 at 08:51:06AM -0800, Matthew Schumacher wrote:
Ok, here is the current plan.
Change the spamassassin API to pass a hash of tokens into the storage
module, pass the tokens to the proc as an array, start a transaction,
load the tokens into a temp table us
On Sun, Jul 31, 2005 at 08:51:06AM -0800, Matthew Schumacher wrote:
> Ok, here is the current plan.
>
> Change the spamassassin API to pass a hash of tokens into the storage
> module, pass the tokens to the proc as an array, start a transaction,
> load the tokens into a temp table using copy, sele
Ok, here is the current plan.
Change the spamassassin API to pass a hash of tokens into the storage
module, pass the tokens to the proc as an array, start a transaction,
load the tokens into a temp table using copy, select the tokens distinct
into the token table for new tokens, update the token t
John Arbash Meinel wrote:
>Matthew Schumacher wrote:
>
>
>
>>All it's doing is trying the update before the insert to get around the
>>problem of not knowing which is needed. With only 2-3 of the queries
>>implemented I'm already back to running about the same speed as the
>>original SA proc th
On 7/30/05 12:57 AM, "William Yu" <[EMAIL PROTECTED]> wrote:
> I haven't investigated the 2.6.12+ kernel updates yet -- I probably will
> do our development servers first to give it a test.
The kernel updates make the NUMA code dual-core aware, which apparently
makes a big difference in some case
Hi Jeff,
which box are you running precisely and which OS/kernel?
We need to run 32bit because we need failover to 32 bit XEON system
(DL580). If this does not work out we probably need to switch to 64 bit
(dump/restore) and run a nother 64bit failover box too.
Regards,
Dirk
Jeffrey W. B
Anybody knows if RedHat is already supporting this patch on an
enterprise version?
Regards,
Dirk
J. Andrew Rogers wrote:
On 7/29/05 10:46 AM, "Josh Berkus" wrote:
does anybody have expierence with this machine (4x 875 dual core Opteron
CPUs)?
Nope. I suspect that you may be the first
11 matches
Mail list logo
