pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedProjecting currentdb to more users
8+ messages / 6 participants
[nested] [flat]
* Projecting currentdb to more users
@ 2005-07-12 16:21 Yves Vindevogel <yves.vindevogel@implements.be>
0 siblings, 1 reply; 8+ messages in thread
From: Yves Vindevogel @ 2005-07-12 16:21 UTC (permalink / raw)
To: pgsql-performance
Hi,
We have a couple of database that are identical (one for each customer).
They are all relatively small, ranging from 100k records to 1m records.
There's only one main table with some smaller tables, a lot of indexes
and some functions.
I would like to make an estimation of the performance, the diskspace
and other related things,
when we have database of for instance 10 million records or 100 million
records.
Is there any math to be done on that ?
Met vriendelijke groeten,
Bien à vous,
Kind regards,
Yves Vindevogel
Implements
Mail: yves.vindevogel@implements.be - Mobile: +32 (478) 80 82 91
Kempische Steenweg 206 - 3500 Hasselt - Tel-Fax: +32 (11) 43 55 76
Web: http://www.implements.be
First they ignore you. Then they laugh at you. Then they fight you.
Then you win.
Mahatma Ghandi.
Attachments:
Pasted Graphic 2.tiff (image/tiff, 5.6K) download
view image
* Re: Projecting currentdb to more users
@ 2005-07-12 18:00 Matthew Nuzum <mattnuzum@gmail.com>
parent: Yves Vindevogel <yves.vindevogel@implements.be>
0 siblings, 0 replies; 8+ messages in thread
From: Matthew Nuzum @ 2005-07-12 18:00 UTC (permalink / raw)
To: Yves Vindevogel <yves.vindevogel@implements.be>; +Cc: pgsql-performance
On 7/12/05, Yves Vindevogel <yves.vindevogel@implements.be> wrote:
> Hi,
>
> We have a couple of database that are identical (one for each customer).
> They are all relatively small, ranging from 100k records to 1m records.
> There's only one main table with some smaller tables, a lot of indexes
> and some functions.
>
> I would like to make an estimation of the performance, the diskspace
> and other related things,
> when we have database of for instance 10 million records or 100 million
> records.
>
> Is there any math to be done on that ?
Its pretty easy to make a database run fast with only a few thousand
records, or even a million records, however things start to slow down
non-linearly when the database grows too big to fit in RAM.
I'm not a guru, but my attempts to do this have not been very accurate.
Maybe (just maybe) you could get an idea by disabling the OS cache on
the file system(s) holding the database and then somehow fragmenting
the drive severly (maybe by putting each table in it's own disk
partition?!?) and measuring performance.
On the positive side, there are a lot of wise people on this list who
have +++ experience optimzing slow queries on big databases. So
queries now that run in 20 ms but slow down to 7 seconds when your
tables grow will likely benefit from optimizing.
--
Matthew Nuzum
www.bearfruit.org
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [PERFORM] Projecting currentdb to more users
@ 2005-07-12 18:24 Mohan, Ross <RMohan@arbinet.com>
0 siblings, 2 replies; 8+ messages in thread
From: Mohan, Ross @ 2005-07-12 18:24 UTC (permalink / raw)
To: pgsql-general@postgresql.org
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [PERFORM] Projecting currentdb to more users
@ 2005-07-12 18:41 Scott Marlowe <smarlowe@g2switchworks.com>
parent: Mohan, Ross <RMohan@arbinet.com>
1 sibling, 1 reply; 8+ messages in thread
From: Scott Marlowe @ 2005-07-12 18:41 UTC (permalink / raw)
To: Mohan, Ross <RMohan@arbinet.com>; +Cc: pgsql-general@postgresql.org
On Tue, 2005-07-12 at 13:24, Mohan, Ross wrote:
> From AMD's suit against Intel. Perhaps relevant to some PG/AMD issues.
>
> "...125. Intel has designed its compiler purposely to degrade performance when a program
> is run on an AMD platform. To achieve this, Intel designed the compiler to compile code
> along several alternate code paths. Some paths are executed when the program runs on an Intel
> platform and others are executed when the program is operated on a computer with an AMD
> microprocessor. (The choice of code path is determined when the program is started, using a
> feature known as "CPUID" which identifies the computer's microprocessor.) By design, the
> code paths were not created equally. If the program detects a "Genuine Intel" microprocessor,
> it executes a fully optimized code path and operates with the maximum efficiency. However,
> if the program detects an "Authentic AMD" microprocessor, it executes a different code path
> that will degrade the program's performance or cause it to crash..."
Well, this is, right now, just AMD's supposition about Intel's
behaviour, I'm not sure one way or the other if Intel IS doing this.
Being a big, money hungry company, I wouldn't be surprised if they are,
but I don't think it would affect postgresql for most people, since they
would be using the gcc compiler.
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [PERFORM] Projecting currentdb to more users
@ 2005-07-12 20:06 Mark Rae <mrae@purplebat.com>
parent: Scott Marlowe <smarlowe@g2switchworks.com>
0 siblings, 1 reply; 8+ messages in thread
From: Mark Rae @ 2005-07-12 20:06 UTC (permalink / raw)
To: Scott Marlowe <smarlowe@g2switchworks.com>; +Cc: Mohan, Ross <RMohan@arbinet.com>; pgsql-general@postgresql.org
On Tue, Jul 12, 2005 at 01:41:14PM -0500, Scott Marlowe wrote:
> On Tue, 2005-07-12 at 13:24, Mohan, Ross wrote:
> > From AMD's suit against Intel. Perhaps relevant to some PG/AMD issues.
> Well, this is, right now, just AMD's supposition about Intel's
> behaviour, I'm not sure one way or the other if Intel IS doing this.
I think its more a case of AMD now having solid evidence to back
up the claims.
This discovery, and that fact that you could get round it by
toggling some flags, was being discussed on various HPC mailing
lists around about the beginning of this year.
-Mark
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [PERFORM] Projecting currentdb to more users
@ 2005-07-12 20:11 Scott Marlowe <smarlowe@g2switchworks.com>
parent: Mark Rae <mrae@purplebat.com>
0 siblings, 1 reply; 8+ messages in thread
From: Scott Marlowe @ 2005-07-12 20:11 UTC (permalink / raw)
To: Mark Rae <mrae@purplebat.com>; +Cc: Mohan, Ross <RMohan@arbinet.com>; pgsql-general@postgresql.org
On Tue, 2005-07-12 at 15:06, Mark Rae wrote:
> On Tue, Jul 12, 2005 at 01:41:14PM -0500, Scott Marlowe wrote:
> > On Tue, 2005-07-12 at 13:24, Mohan, Ross wrote:
> > > From AMD's suit against Intel. Perhaps relevant to some PG/AMD issues.
> > Well, this is, right now, just AMD's supposition about Intel's
> > behaviour, I'm not sure one way or the other if Intel IS doing this.
>
> I think its more a case of AMD now having solid evidence to back
> up the claims.
>
> This discovery, and that fact that you could get round it by
> toggling some flags, was being discussed on various HPC mailing
> lists around about the beginning of this year.
Wow! That's pretty fascinating. So, is the evidence pretty
overwhelming that this was not simple incompetence, but real malice?
I could see either one being a cause of this issue, and wouldn't really
be surprised by either one.
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [PERFORM] Projecting currentdb to more users
@ 2005-07-12 20:32 Mark Rae <mrae@purplebat.com>
parent: Scott Marlowe <smarlowe@g2switchworks.com>
0 siblings, 0 replies; 8+ messages in thread
From: Mark Rae @ 2005-07-12 20:32 UTC (permalink / raw)
To: Scott Marlowe <smarlowe@g2switchworks.com>; +Cc: Mohan, Ross <RMohan@arbinet.com>; pgsql-general@postgresql.org
On Tue, Jul 12, 2005 at 03:11:35PM -0500, Scott Marlowe wrote:
> On Tue, 2005-07-12 at 15:06, Mark Rae wrote:
> > I think its more a case of AMD now having solid evidence to back
> > up the claims.
>
> Wow! That's pretty fascinating. So, is the evidence pretty
> overwhelming that this was not simple incompetence, but real malice?
I suppose that depends on the exact nature of the 'check'.
As far as I was aware it was more a case of 'I don't recognise this
processor, so I'll do it the slow but safe way'.
However from what AMD are claiming, it seems to be more of a
'Its an AMD processor so I'll be deliberately slow and buggy'
Having said that, I have tried compiling PG with the intel compiler
in the past, and haven't noticed any real difference. But in a database
there isn't much scope for vectorization and pipelining
compared with numerical code, which is where the Intel compiler
makes the greatest difference.
-Mark
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Projecting currentdb to more users
@ 2005-07-13 05:18 Jean-Max Reymond <jmreymond@gmail.com>
parent: Mohan, Ross <RMohan@arbinet.com>
1 sibling, 0 replies; 8+ messages in thread
From: Jean-Max Reymond @ 2005-07-13 05:18 UTC (permalink / raw)
To: pgsql-performance
2005/7/12, Mohan, Ross <RMohan@arbinet.com>:
> From AMD's suit against Intel. Perhaps relevant to some PG/AMD issues.
Postgres is compiled with gnu compiler. Isn't it ?
I don't know how much can Postgres benefit from an optimized Intel compiler.
--
Jean-Max Reymond
CKR Solutions Open Source
Nice France
http://www.ckr-solutions.com
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2005-07-13 05:18 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-07-12 16:21 Projecting currentdb to more users Yves Vindevogel <yves.vindevogel@implements.be>
2005-07-12 18:00 ` Matthew Nuzum <mattnuzum@gmail.com>
2005-07-12 18:24 Re: [PERFORM] Projecting currentdb to more users Mohan, Ross <RMohan@arbinet.com>
2005-07-12 18:41 ` Scott Marlowe <smarlowe@g2switchworks.com>
2005-07-12 20:06 ` Mark Rae <mrae@purplebat.com>
2005-07-12 20:11 ` Scott Marlowe <smarlowe@g2switchworks.com>
2005-07-12 20:32 ` Mark Rae <mrae@purplebat.com>
2005-07-13 05:18 ` Jean-Max Reymond <jmreymond@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox