Rosser Schwarz wrote:
> while you weren't looking, Kevin Brown wrote:
>
> [reordering bursty reads]
>
> > In other words, it's a corner case that I strongly suspect
> > isn't typical in situations where SCSI has historically made a big
> > difference.
>
> [...]
>
> > But I rather doubt that has
Vivek Khera wrote:
>
> On Apr 14, 2005, at 10:03 PM, Kevin Brown wrote:
>
> >Now, bad block remapping destroys that guarantee, but unless you've
> >got a LOT of bad blocks, it shouldn't destroy your performance, right?
> >
>
> ALL disks have bad blocks, even when you receive them. you honestly
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > In the case of pure random reads, you'll end up having to wait an
> > average of half of a rotation before beginning the read.
>
> You're assuming the conclusion. The above is true if the disk is handed
> one request at a time by a ker
Rod Taylor wrote:
> On Fri, 2005-04-15 at 15:43 -0500, Matthew Nuzum wrote:
>> * I agree with the threads that more disks are better.
>> * I also agree that SCSI is better, but can be hard to justify
Here's another approach to spend $7000 that we're currently
trying but it'll only work for cert
"Joel Fradkin" <[EMAIL PROTECTED]> writes:
> Turning off merg joins seems to of done it but what do I need to do so I am
> not telling the system explicitly not to use them, I must be missing some
> setting?
> " -> Hash Left Join (cost=185.57..226218.77 rows=177236 width=75) (actual
> time=21.1
On Fri, 2005-04-15 at 15:43 -0500, Matthew Nuzum wrote:
> I think there are many people who feel that $7,000 is a good budget for a
> database server, me being one.
The budget for a database server is usually some %age of the value of
the data within the database or the value of it's availability.
Tom,
People's opinions on pgbench may vary, so take what I say with a grain
of salt. Here are my thoughts:
1) Test with no less than 200 transactions per client. I've heard with
less than this, your results will vary too much with the direction of
the wind blowing. A high enough value will help
"Thomas F.O'Connell" <[EMAIL PROTECTED]> writes:
> http://www.sitening.com/pgbench.html
You need to run *many* more transactions than that to get pgbench
numbers that aren't mostly noise. In my experience 1000 transactions
per client is a rock-bottom minimum to get repeatable numbers; 1 per
i
Enrico Weigelt <[EMAIL PROTECTED]> writes:
> c) CREATE FUNCTION id2username(oid) RETURNS text
> LANGUAGE 'SQL' IMMUTABLE AS '
> SELECT username AS RESULT FROM users WHERE uid = $1';
This is simply dangerous. The function is *NOT* immutable (it is
stable though). When ... not if ... yo
I'm in the fortunate position of having a newly built database server
that's pre-production. I'm about to run it through the ringer with some
simulations of business data and logic, but I wanted to post the
results of some preliminary pgbench marking.
http://www.sitening.com/pgbench.html
To me,
Hi folks,
I like to use (immutable) functions for looking up serveral
(almost constant) things, i.e fetching a username by id.
This makes my queries more clear.
But is this really performant ?
Lets imagine:
We've got an table with user accounts (uid,name,...). Then we've
got another one whi
* Stephan Szabo <[EMAIL PROTECTED]> wrote:
>
> On Thu, 24 Mar 2005, Enrico Weigelt wrote:
>
> > * Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > > On Thu, Mar 24, 2005 at 02:32:48PM +0100, Enrico Weigelt wrote:
> > >
> > > > BTW: is it possible to explicitly clear the cache for immutable
> > > > f
I think there are many people who feel that $7,000 is a good budget for a
database server, me being one.
* I agree with the threads that more disks are better.
* I also agree that SCSI is better, but can be hard to justify if your
budget is tight, and I have great certainty that 2x SATA drives o
Greg, et al.
I never found any evidence of a "stop and get an intermediate request"
functionality in the TCQ protocol.
IIRC, what is there is
1) Ordered
2) Head First
3) Simple
implemented as choices. *VERY* roughly, that'd be like
(1) disk subsystem satisfies requests as submitted, (2) let's
Joel Fradkin
Turning off merg joins seems to of done it but what do I need to do so I am
not telling the system explicitly not to use them, I must be missing some
setting?
On linux box.
explain analyze select * from viwassoclist where clientnum ='SAKS'
"Hash Join (cost=988.25..292835.36 row
Ross,
I agree with you, but I' am the lowly intergrator/analyst, I have to solve the
problem without all
the authority (sounds like a project manager). I originally started this thread
since I had the $7k budget.
I am not a dba/developer. but I play one on t.v., so I can only assume that
throwin
Tom Lane <[EMAIL PROTECTED]> writes:
> Yes, you can probably assume that blocks with far-apart numbers are
> going to require a big seek, and you might even be right in supposing
> that a block with an intermediate number should be read on the way.
> But you have no hope at all of making the right
Sorry to blend threads, but in my kinda longish, somewhat thankless,
essentially anonymous, and quite average career as a dba, I have
found that the 7K would be best spent on a definitive end-to-end
"application critical path" test (pretty easy to instrument apps
and lash on test harnesses these
Alex Turner wrote:
No offense to that review, but it was really wasn't that good, and
drew bad conclusions from the data. I posted it originaly and
immediately regretted it.
See http://www.tweakers.net/reviews/557/18
Amazingly the controller with 1Gig cache manages a write throughput of
750MB/sec
I stand corrected!
Maybe I should re-evaluate our own config!
Alex T
(The dell PERC controllers do pretty much suck on linux)
On 4/15/05, Vivek Khera <[EMAIL PROTECTED]> wrote:
>
> On Apr 15, 2005, at 11:01 AM, Alex Turner wrote:
>
> > You can't fit a 15k RPM SCSI solution into $7K ;) Some o
On Apr 15, 2005, at 11:58 AM, Joshua D. Drake wrote:
ALL disks have bad blocks, even when you receive them. you honestly
think that these large disks made today (18+ GB is the smallest now)
that there are no defects on the surfaces?
That is correct. It is just that the HD makers will mark the ba
Vivek Khera wrote:
On Apr 14, 2005, at 10:03 PM, Kevin Brown wrote:
Now, bad block remapping destroys that guarantee, but unless you've
got a LOT of bad blocks, it shouldn't destroy your performance, right?
ALL disks have bad blocks, even when you receive them. you honestly
think that these large
On Apr 15, 2005, at 11:01 AM, Alex Turner wrote:
You can't fit a 15k RPM SCSI solution into $7K ;) Some of us are on a
budget!
I just bought a pair of Dual Opteron, 4GB RAM, LSI 320-2X RAID dual
channel with 8 36GB 15kRPM seagate drives. Each one of these boxes set
me back just over $7k, incl
On Apr 14, 2005, at 10:03 PM, Kevin Brown wrote:
Now, bad block remapping destroys that guarantee, but unless you've
got a LOT of bad blocks, it shouldn't destroy your performance, right?
ALL disks have bad blocks, even when you receive them. you honestly
think that these large disks made today (
This is a different thread that the $7k server thread.
Greg Stark started it and wrote:
"I'm also wondering about whether I'm better off with one of these
SATA raid
con
> -Original Message-
> From: Alex Turner [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 15, 2005 9:44 AM
> To: Marinos Yannikos
> Cc: Joshua D. Drake; Mohan, Ross; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Intel SRCS16 SATA raid?
>
> No offense to that review, but it was r
The original thread was how much can I get for $7k
You can't fit a 15k RPM SCSI solution into $7K ;) Some of us are on a budget!
10k RPM SATA drives give acceptable performance at a good price, thats
really the point here.
I have never really argued that SATA is going to match SCSI
performance
No offense to that review, but it was really wasn't that good, and
drew bad conclusions from the data. I posted it originaly and
immediately regretted it.
See http://www.tweakers.net/reviews/557/18
Amazingly the controller with 1Gig cache manages a write throughput of
750MB/sec on a single drive
Dave wrote "An interesting test would be to stick several drives in a
cabinet and
graph how performance is affected at the different price points/
technologies/number of drives."
>From the discussion on the $7k server thread, it seems the RAID controller
would
be an important data point also. And
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Alex) belched out:
> i am thinking about swiching to plperl as it seems to me much more
> flexible and easier to create functions.
>
> what is the recommended PL for postgres? or which one is most widely
> used / most popular?
> is there
"Joel Fradkin" <[EMAIL PROTECTED]> writes:
> "Merge Join (cost=49697.60..50744.71 rows=14987 width=113) (actual
> time=11301.160..12171.072 rows=160593 loops=1)"
> " Merge Cond: ("outer".locationid = "inner".locationid)"
> " -> Sort (cost=788.81..789.89 rows=432 width=49) (actual
> time=3.318.
Tom Lane wrote:
You didn't show us any \timing. The 94.109 ms figure is all server-side.
Whoop, my mistake. I had been retesting without the explain, just the
query. I re-run the explain analyze a few times, and it only reports
90ms the first time. After that it reports 2ms even over the network
Richard van den Berg <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>> No explain analyze is done on the server...
> Yes, but the psql \timing is calculated on the client, right? That is
> the value that PFC was refering to.
You didn't show us any \timing. The 94.109 ms figure is
> -Original Message-
> From: Alex Turner [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 14, 2005 6:15 PM
> To: Dave Held
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] Intel SRCS16 SATA raid?
>
> Looking at the numbers, the raptor with TCQ enabled was close or
> beat th
It is still slower on the Linux box. (included is explain with SET
enable_seqscan = off;
explain analyze select * from viwassoclist where clientnum ='SAKS') See
below.
I did a few other tests (changing drive arrays helped by 1 second was slower
on my raid 10 on the powervault).
Pulling just raw d
PFC wrote:
My argument is that a sufficiently smart kernel scheduler *should*
yield performance results that are reasonably close to what you can
get with that feature. Perhaps not quite as good, but reasonably
close. It shouldn't be an orders-of-magnitude type difference.
And a controller
Christopher Kings-Lynne wrote:
No explain analyze is done on the server...
Yes, but the psql \timing is calculated on the client, right? That is
the value that PFC was refering to.
--
Richard van den Berg, CISSP
---
Trust Factory B.V. | www.dna-portal.n
Hi,
i am thinking about swiching to plperl as it seems to me much more
flexible and easier to create functions.
what is the recommended PL for postgres? or which one is most widely
used / most popular?
is there a performance difference between plpgsql and plperl ?
porting to other systems is no
Am I correct is assuming that the timings are calculated locally by psql
on my client, thus including network latency?
No explain analyze is done on the server...
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL P
PFC wrote:
94 ms for an index scan ?
this look really slow...
That seems to be network latency. My psql client is connecting over
ethernet to the database server. Retrying the command gives very
different values, as low as 20ms. That 94ms was the highest I've seen.
Running the same comma
Joshua D. Drake wrote:
Well I have never even heard of it. 3ware is the defacto authority of
reasonable SATA RAID.
no! 3ware was rather early in this business, but there are plenty of
(IMHO, and some other people's opinion) better alternatives available.
3ware has good Linux drivers, but the pe
Index Scan using ix_B on B (cost=0.04..3.06 rows=1 width=329) (actual
time=93.824..93.826 rows=1 loops=1)
Index Cond: (id = $0)
InitPlan
-> Limit (cost=0.00..0.04 rows=1 width=4) (actual
time=15.128..15.129 rows=1 loops=1)
-> Seq Scan on A (cost=0.00..47569.70 row
platter compared to the rotational speed, which would agree with the
fact that you can read 70MB/sec, but it takes up to 13ms to seek.
Actually :
- the head has to be moved
this time depends on the distance, for instance moving from a cylinder to
the next is very fast (it needs to, to get goo
My argument is that a sufficiently smart kernel scheduler *should*
yield performance results that are reasonably close to what you can
get with that feature. Perhaps not quite as good, but reasonably
close. It shouldn't be an orders-of-magnitude type difference.
And a controller card (or drive)
PFC wrote:
You're using 7.4.5. It's possible that you have a type mismatch in
your foreign keys which prevents use of the index on B.
I read about this pothole and made damn sure the types match. (Actually,
I kinda hoped that was the problem, it would have been an easy fix.)
First of al
45 matches
Mail list logo
