Cosimo Streppone <[EMAIL PROTECTED]> writes:
> The performance level of Pg 8 is at least *five* times higher
> (faster!) than 7.1.3 in "query-intensive" transactions,
> which is absolutely astounding.
Cool.
> In my experience, Pg8 handles far better non-unique indexes
> with low cardinality built
Cosimo Streppone wrote:
Merlin Moncure wrote:
> If everything is working the way it's supposed to, 8.0 should be faster
> than 7.1 (like, twice faster) for what you are probably trying to do.
In the next days I will be testing the entire application with the
same database only changing the backend
pgman@candle.pha.pa.us (Bruce Momjian) wrote:
> William Yu wrote:
>> > Well, that would give you the most benefit, but the memory
>> > bandwidth is still greater than on a Xeon. There's really no
>> > issue with 64 bit if you're using open source software; it all
>> > compiles for 64 bits and you'r
Merlin Moncure wrote:
> [...]
> > (...DBI + DBD::Pg), so that switching to 8.0 should
> automatically enable the "single-prepare, multiple-execute" behavior,
> saving a lot of query planner processing, if I understand correctly.
[...]
I know that the perl people were pushing for certain features in
> By now, our system has never used "stored procedures" approach,
> due to the fact that we're staying on the minimum common SQL features
> that are supported by most db engines.
> I realize though that it would provide an heavy performance boost.
I feel your pain. Well, sometimes you have to bi
Bruce Momjian wrote:
William Yu wrote:
You can get 64-bit Xeons also but it takes hit in the I/O department due
to the lack of a hardware I/O MMU which limits DMA transfers to
addresses below 4GB. This has a two-fold impact:
1) transfering data to >4GB require first a transfer to <4GB and then a
William Yu wrote:
> >>You can get 64-bit Xeons also but it takes hit in the I/O department due
> >>to the lack of a hardware I/O MMU which limits DMA transfers to
> >>addresses below 4GB. This has a two-fold impact:
> >>
> >>1) transfering data to >4GB require first a transfer to <4GB and then a
You can get 64-bit Xeons also but it takes hit in the I/O department due
to the lack of a hardware I/O MMU which limits DMA transfers to
addresses below 4GB. This has a two-fold impact:
1) transfering data to >4GB require first a transfer to <4GB and then a
copy to the final destination.
2) Yo
William Yu wrote:
> > Well, that would give you the most benefit, but the memory bandwidth is
> > still greater than on a Xeon. There's really no issue with 64 bit if
> > you're using open source software; it all compiles for 64 bits and
> > you're good to go. http://stats.distributed.net runs on a
None - but I'll definately take a look..
Alex Turner
NetEconomist
On Tue, 01 Feb 2005 22:11:30 +0100, Cosimo Streppone
<[EMAIL PROTECTED]> wrote:
> Alex Turner wrote:
>
> > To be honest I've used compaq, dell and LSI SCSI RAID controllers and
> > got pretty pathetic benchmarks from all of them.
Jim C. Nasby wrote:
On Tue, Feb 01, 2005 at 07:35:35AM +0100, Cosimo Streppone wrote:
You might look at Opteron's, which theoretically have a higher data
bandwidth. If you're doing anything data intensive, like a sort in
memory, this could make a difference.
Would Opteron systems need 64-bit postgr
Alex Turner wrote:
To be honest I've used compaq, dell and LSI SCSI RAID controllers and
got pretty pathetic benchmarks from all of them.
I also have seen average-low results for LSI (at least the 1020 card).
2xOpteron 242, Tyan S2885 MoBo, 4GB Ram, 14xSATA WD Raptor drives:
2xRaid 1, 1x4 disk Raid
Merlin Moncure wrote:
Corollary: use pl/pgsql. It can be 10 times or more faster than query
by query editing.
Merlin, thanks for your good suggestions.
By now, our system has never used "stored procedures" approach,
due to the fact that we're staying on the minimum common SQL features
that are sup
> Hi all,
> 1) What kind of performance gain can I expect switching from
> 7.1 to 7.4 (or 8.0)? Obviously I'm doing my own testing,
> but I'm not very impressed by 8.0 speed, may be I'm doing
> testing on a low end server...
8.0 gives you savepoints. While this may not seem like a big
To be honest I've used compaq, dell and LSI SCSI RAID controllers and
got pretty pathetic benchmarks from all of them. The best system I
have is the one I just built:
2xOpteron 242, Tyan S2885 MoBo, 4GB Ram, 14xSATA WD Raptor drives:
2xRaid 1, 1x4 disk Raid 10, 1x6 drive Raid 10. 2x3ware (now AM
On Tue, Feb 01, 2005 at 07:35:35AM +0100, Cosimo Streppone wrote:
> >You might look at Opteron's, which theoretically have a higher data
> >bandwidth. If you're doing anything data intensive, like a sort in
> >memory, this could make a difference.
>
> Would Opteron systems need 64-bit postgresql (
Jim C. Nasby wrote:
On Mon, Jan 31, 2005 at 09:41:32PM +0100, Cosimo wrote:
>2) The goal is to make the db handle 100 tps (something like
> 100 users). What kind of server and storage should I provide?
You might look at Opteron's, which theoretically have a higher data
bandwidth. If you're doing
Tom Lane wrote:
Cosimo writes:
1) What kind of performance gain can I expect switching from
7.1 to 7.4 (or 8.0)? Obviously I'm doing my own testing,
but I'm not very impressed by 8.0 speed, may be I'm doing
testing on a low end server...
Most people report a noticeable speedup in each new
On Mon, Jan 31, 2005 at 09:41:32PM +0100, Cosimo Streppone wrote:
> 2) The goal is to make the db handle 100 tps (something like
>100 users). What kind of server and storage should I provide?
>
>The actual servers our application runs on normally have
>2 Intel Xeon processors, 2-4 Gb R
Cosimo Streppone <[EMAIL PROTECTED]> writes:
> 1) What kind of performance gain can I expect switching from
> 7.1 to 7.4 (or 8.0)? Obviously I'm doing my own testing,
> but I'm not very impressed by 8.0 speed, may be I'm doing
> testing on a low end server...
Most people report a notic
20 matches
Mail list logo
