On Mon, Aug 11, 2008 at 2:53 AM, Sabin Coanda
<[EMAIL PROTECTED]> wrote:
> No, I cannot use VACUUM inside the transaction, and it seems this is the
> problem, although autovacuum is set.
>
> However I checked the following scenario to find a solution. I call the
> 3 statements without transacti
Valentin Bogdanov wrote:
--- On Mon, 11/8/08, Gregory Stark <[EMAIL PROTECTED]> wrote:
From: Gregory Stark <[EMAIL PROTECTED]>
Subject: Re: [PERFORM] Using PK value as a String
To: "Jay" <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org
Date: Monday, 11 August, 2008, 10:30 AM
"Jay" <[EMA
On Mon, Aug 11, 2008 at 8:26 AM, dforums <[EMAIL PROTECTED]> wrote:
> Houlala
>
> I got headache !!!
>
> So please help...;;
>
> "Assuming they all happen from 9 to 5 and during business days only,
> that's about 86 transactions per second. Well within the realm of a
> single mirror set to
On Sun, 10 Aug 2008, Henrik wrote:
Normally, when a SATA implementation is running significantly faster than a
SAS one, it's because there's some write cache in the SATA disks turned on
(which they usually are unless you go out of your way to disable them).
Lucky for my I have BBU on all my co
> -Mensaje original-
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] En nombre de dforums
> Enviado el: Lunes, 11 de Agosto de 2008 11:27
> Para: Scott Marlowe; pgsql-performance@postgresql.org
> Asunto: Re: [PERFORM] Distant mirroring
>
> Houlala
>
> I got headache !!!
>
> So plea
On Aug 11, 2008, at 5:17 AM, Henrik wrote:
OK, changed the SAS RAID 10 to RAID 5 and now my random writes are
handing 112 MB/ sek. So it is almsot twice as fast as the RAID10
with the same disks. Any ideas why?
Is the iozone tests faulty?
does IOzone disable the os caches?
If not you ne
unregister
Houlala
I got headache !!!
So please help...;;
"Assuming they all happen from 9 to 5 and during business days only,
that's about 86 transactions per second. Well within the realm of a
single mirror set to keep up if you don't make your db work real fat."
OK i like, But my reality is t
On Mon, Aug 11, 2008 at 6:08 AM, Henrik <[EMAIL PROTECTED]> wrote:
> 11 aug 2008 kl. 12.35 skrev Glyn Astill:
>
> It feels like there is something fishy going on.
>>>
>>> Maybe the RAID 10
>
> implementation on the PERC/6e is crap?
>>
>> It's possible. We had a bunch of perc/
On Aug 11, 2008, at 4:30 AM, Gregory Stark wrote:
"Jay" <[EMAIL PROTECTED]> writes:
I have a table named table_Users:
CREATE TABLE table_Users (
UserID character(40) NOT NULL default '',
Username varchar(256) NOT NULL default '',
Email varchar(256) NOT NULL default '
11 aug 2008 kl. 12.35 skrev Glyn Astill:
It feels like there is something fishy going on.
Maybe the RAID 10
implementation on the PERC/6e is crap?
It's possible. We had a bunch of perc/5i SAS raid cards in our
servers that performed quite well in Raid 5 but were shite in Raid
10. I
> >
> >> It feels like there is something fishy going on.
> Maybe the RAID 10
> >> implementation on the PERC/6e is crap?
> >
It's possible. We had a bunch of perc/5i SAS raid cards in our servers that
performed quite well in Raid 5 but were shite in Raid 10. I switched them out
for Adaptec
If UserID just be unique internal key and the unique id of other tables, I'd
like sequence, which is unique and just use 8 bytes(bigint) When it querying
other tables, it will faster , and disk space smaller than UUID(40 bytes).
莫建祥
阿里巴巴软件(上海)有限公司
研发中心－IM服务端开发部
联系方式:86-0571-85022088-
--- On Mon, 11/8/08, Gregory Stark <[EMAIL PROTECTED]> wrote:
> From: Gregory Stark <[EMAIL PROTECTED]>
> Subject: Re: [PERFORM] Using PK value as a String
> To: "Jay" <[EMAIL PROTECTED]>
> Cc: pgsql-performance@postgresql.org
> Date: Monday, 11 August, 2008, 10:30 AM
> "Jay" <[EMAIL PROTECTED]> w
"Jay" <[EMAIL PROTECTED]> writes:
> I have a table named table_Users:
>
> CREATE TABLE table_Users (
>UserID character(40) NOT NULL default '',
>Username varchar(256) NOT NULL default '',
>Email varchar(256) NOT NULL default ''
>etc...
> );
>
> The UserID is a ch
OK, changed the SAS RAID 10 to RAID 5 and now my random writes are
handing 112 MB/ sek. So it is almsot twice as fast as the RAID10 with
the same disks. Any ideas why?
Is the iozone tests faulty?
What is your suggestions? Trust the IOZone tests and use RAID5 instead
of RAID10, or go for RA
I have a table named table_Users:
CREATE TABLE table_Users (
UserID character(40) NOT NULL default '',
Username varchar(256) NOT NULL default '',
Email varchar(256) NOT NULL default ''
etc...
);
The UserID is a character(40) and is generated using UUID function. We
No, I cannot use VACUUM inside the transaction, and it seems this is the
problem, although autovacuum is set.
However I checked the following scenario to find a solution. I call the
3 statements without transaction. The performance it not changed. But
when I add VACUUM command after each 20
18 matches
Mail list logo
