William Yu <[EMAIL PROTECTED]> writes:
> In terms of Postgres database performance, Opteron *may* be the better
> CPU for this app but there's not enough data points yet. Here's a recent
> review at Anandtech showing Opteron 150 (2.4ghz) versus 64-bit Prescott
> 3.6hgz with some very simple MySQ
Raoul Buzziol wrote:
I looked for some benchmarks, and I would know if I'm right on:
- Dual Opteron 246 have aproximately the same performance of a Dual Xeon 3Gh
(Opteron a little better)
- Opteron system equal or cheeper than Xeon system.
In terms of general database performance, top of the line d
Thanks a lot. This issue has been resolved by casting to int8. I thought Postgres does
those casts
up by himself implicitelly.
=
Thanks a lot
Igor Artimenko
I specialize in
Java, J2EE, Unix, Linux, HP, AIX, Solaris, Progress, Oracle, DB2, Postgres, Data
Modeling
_
Since you are updating all of the sets with the specified part number
why not just ensure that a transaction never inserts the same part
number more than once (an INSERT ...SELECT ... WHERE NOT EXISTS(...)
comes to mind), then delete the row before the end of transaction.
Frank van Vugt wrote:
You got it.. 7.3 (should have mentioned that). We're planning to
upgrade to 8.0 anyway in the future, so it's good to know. Thanks!
-Aaron
On Wed, 18 Aug 2004 17:39:21 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
> Aaron Birkland <[EMAIL PROTECTED]> writes:
> > In a nutshell, it looks like wh
Aaron Birkland <[EMAIL PROTECTED]> writes:
> In a nutshell, it looks like whenever COPY is invoked, and when a user
> defined type is used in an array, then stat64() will be called for
> each row accessed on the shared library relevant for the user defined
> type.
Let me guess ... PG 7.3 or older?
Hi,
I noticed an interesting phenomenon when loding (COPY) some tables
from a file. For some reason, one load was taking longer than I
assumed it would. As it turns out, one of the columns was an array
containing elements that were of a user defined type. Using strace
(on linux) and truss (on
I ("gnari" <[EMAIL PROTECTED]>) miswrote:
> Actually, I think it was determined that the problem was due to the
> int index
of course, i meant int8 index
gnari
---(end of broadcast)---
TIP 8: explain analyze is your friend
"Thomas Swan" <[EMAIL PROTECTED]> says:
> Igor Artimenko wrote:
>
[ snipped question that was almost exactly a repeat
of one we saw yesterday ]
> >
> >
> Igor, you may want to run "vacuum analyze" and see if your results change.
Actually, I think it was determined that the problem was due to
Igor Artimenko wrote:
Hi verybody!
I can't make use of indexes even I tried the same test by changing different settings in postgres.conf like geqo to off/on & geqo related parameters, enable_seqscan off/on & so on. Result is the same.
Here is test itself:
I've created simplest table test and exe
On Wed, 2004-08-18 at 11:18, Raoul Buzziol wrote:
> > You're not going to be able to get a Dual Athlon MP for the same price
> > as a single Xeon. A few years back, this was the case because Xeon CPUs
> > & MBs had a huge premium over Athlon. This is no longer true mainly
> > because the number of
> You're not going to be able to get a Dual Athlon MP for the same price
> as a single Xeon. A few years back, this was the case because Xeon CPUs
> & MBs had a huge premium over Athlon. This is no longer true mainly
> because the number of people carrying Athlon MP motherboards has dropped
> down
Hi verybody!
I can't make use of indexes even I tried the same test by changing different settings
in postgres.conf like geqo to off/on & geqo related parameters, enable_seqscan off/on
& so on. Result is the same.
Here is test itself:
I've created simplest table test and executed the same sta
On 8/17/2004 8:44 PM, my thi ho wrote:
Hi,
I am working on a project which explore postgresql to
store multimedia data.
In details, i am trying to work with the buffer
management part of postgres source code. And try to
improve the performance. I had search on the web but
could not find much usefu
On Aug 18, 2004, at 4:18 AM, eleven wrote:
Hello,
This is not strictly PostgreSQL performance hint, but may be
helpful to someone with problems like mine.
As I earlier posted, I was experiencing very high load average
on one of my Linux database servers (IBM eServer 345, SCSI disks on
LSI Logic co
eleven wrote:
Hello,
This is not strictly PostgreSQL performance hint, but may be
helpful to someone with problems like mine.
As I earlier posted, I was experiencing very high load average
on one of my Linux database servers (IBM eServer 345, SCSI disks on LSI
Logic controller) caused by I/O bottl
Hi Josh,
> > It seems in this case the time needed for a single deferred trigger
> > somehow depends on the number of dead tuples in the table
After further investigation I think I have a better grasp of what's going on.
The thing biting me here is indeed the 'delete from' on a table with a numb
...and on Wed, Aug 18, 2004 at 10:18:19AM +0200, eleven used the keyboard:
> Hello,
>
> This is not strictly PostgreSQL performance hint, but may be
> helpful to someone with problems like mine.
>
> As I earlier posted, I was experiencing very high load average
> on one of my Linux database serve
Hello,
This is not strictly PostgreSQL performance hint, but may be
helpful to someone with problems like mine.
As I earlier posted, I was experiencing very high load average
on one of my Linux database servers (IBM eServer 345, SCSI disks on LSI
Logic controller) caused by I/O bottleneck.
INSERT
19 matches
Mail list logo
