* Guoping Zhang:
> a) Anyone has the similar experience? How do you deal with it?
> b) Why TCP stack imposes such big delay? any tuning point I shall do?
If you use INSERT, you'll incur a network round-trip delay for each
record. Try using COPY FROM instead, possibly to a temporary table if
Hello,
I am seeking advice/comment/experience you may have had for the performance
cost for remote access to postgresql 8.1.X?
I have two servers, one is Sun V240 (say server A) and the other is dual
intel Xeon (say Server B) and both installed Solaris 10.
With Server A, there is postgresql 8.1
Hi Chris, Here are the results of my query for postgresql 8.0.3 and 8.1.4. For postgresql 8.1.4 there are 2 results, one for test table having the same indexes as in 8.0.3 and the second one for a new index on test table by (testtype,testid) that will speed up my query. This last index will f
According to
http://www.pcguide.com/ref/hdd/perf/raid/concepts/perfStripe-c.html, it seems
to be the other way around?
("As stripe size is decreased, files are broken into smaller and smaller
pieces. This increases the number of drives
that an average file will use to hold all the blocks contain
Nope, haven't tried that. At the time I was testing this I didn't even
think of trying it. I'm not even sure I'd heard of RAID 50 at the
time... :)
I basically had an old MegaRAID 4xx series card in a dual PPro 200 and a
stack of 6 9 gig hard drives. Spare parts. And even though the RAID
1+0 w
Have you done any experiments implementing RAID 50 this way (HBA does RAID 5,
OS does RAID 0)? If so, what were the results?
Ron
-Original Message-
>From: Scott Marlowe <[EMAIL PROTECTED]>
>Sent: Jul 18, 2006 3:37 PM
>To: Alex Turner <[EMAIL PROTECTED]>
>Cc: Luke Lonergan <[EMAIL PROTEC
On Tue, 2006-07-18 at 14:27, Alex Turner wrote:
> This is a great testament to the fact that very often software RAID
> will seriously outperform hardware RAID because the OS guys who
> implemented it took the time to do it right, as compared with some
> controller manufacturers who seem to think i
This is a great testament to the fact that very often software RAID will seriously outperform hardware RAID because the OS guys who implemented it took the time to do it right, as compared with some controller manufacturers who seem to think it's okay to provided sub-standard performance.
Based on
Title: Re: [PERFORM] RAID stripe size question
Mikael,
On 7/18/06 6:34 AM, "Mikael Carneholm" <[EMAIL PROTECTED]> wrote:
> However, what's more important is the seeks/s - ~530/s on a 28 disk
> array is quite lousy compared to the 1400/s on a 12 x 15Kdisk array
I'm getting 2500 seeks/second on
On Jul 18, 2006, at 6:22 AM, Gavin Sherry wrote:
On Tue, 18 Jul 2006, Rusty Conover wrote:
Hi,
It would seem that doing any changes on a temp table forces a copy of
the entire contents of the table to be retained in memory/disk. Is
this happening due to MVCC? Is there a way to change this
> This is a relatively low end HBA with 1 4Gb FC on it. Max sustained
IO on it is going to be ~320MBps. Or ~ enough for an 8 HD RAID 10 set
made of 75MBps ASTR HD's.
Looking at http://h30094.www3.hp.com/product.asp?sku=2260908&extended=1,
I notice that the controller has a Ultra160 SCSI interfac
>From: Alex Turner <[EMAIL PROTECTED]>
>Sent: Jul 18, 2006 12:21 AM
>To: Ron Peacetree <[EMAIL PROTECTED]>
>Cc: Mikael Carneholm <[EMAIL PROTECTED]>, pgsql-performance@postgresql.org
>Subject: Re: [PERFORM] RAID stripe size question
>
>On 7/17/06, Ron Peacetree <[EMAIL PROTECTED]> wrote:
>>
>>
On Tue, 18 Jul 2006, Rusty Conover wrote:
> Hi,
>
> It would seem that doing any changes on a temp table forces a copy of
> the entire contents of the table to be retained in memory/disk. Is
> this happening due to MVCC? Is there a way to change this behavior?
> It could be very useful when you
Hi,
It would seem that doing any changes on a temp table forces a copy of
the entire contents of the table to be retained in memory/disk. Is
this happening due to MVCC? Is there a way to change this behavior?
It could be very useful when you have really huge temp tables that
need to be
Sorry for replying to my own post.
I forgot to include my version information, I used:
PostgreSQL 8.1.0 on powerpc-apple-darwin8.3.0, compiled by GCC
powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, Inc.
build 5026)
and
PostgreSQL 8.1.3 on i686-pc-linux-gnu, compiled by GCC gc
Il giorno dom, 16/07/2006 alle 11.08 -0700, Joe Conway ha scritto:
> Gabriele Turchi wrote:
> > Il giorno sab, 15/07/2006 alle 13.04 -0700, Joe Conway ha scritto:
> >>Why not just periodically (once an hour?) run "ANALYZE registrazioni;"
> >>during the day. This will only update the statistics, an
Yes that was the problem! Thank you very much
On Thu, 13 Jul 2006, Tom Lane wrote:
[EMAIL PROTECTED] writes:
... is quite reasonable.The table has 1.000.000 rows (17.242 pages). From
pg_stat_get_blocks_fetched I can see that there were 102 page requests for
table. So all things seem to work g
17 matches
Mail list logo
