I missed the initial post in this thread, but I haven't seen any 15K rpm
2.5 drives, so if you compare 10K rpm 2.5 drives with 15K rpm 3.5
drives you will see differences (depending on your workload and controller
cache)
I have some 15K rpm 2.5 sas-drives from HP. Other vendors have them as
Hi Tom,
Is there any way to work out what plan the query is using in side the
function? I think I have a similar problem with a query taking much
longer from inside a function than it does as a select statement.
Regards
Matthew
Tom Lane wrote:
Claire McLister [EMAIL PROTECTED] writes:
You don't mention the capacity of the disks you are looking at. Here is
something you might want to consider.
I've seen a few performance posts on using different hardware
technologies to gain improvements. Most of those comments are on raid,
interface and rotation speed. One area that
On Tue, Jan 29, 2008 at 9:52 AM, in message
[EMAIL PROTECTED], Gregory Stark [EMAIL PROTECTED]
wrote:
I got this from a back-of-the-envelope calculation which now that I'm trying
to reproduce it seems to be wrong. Previously I thought it was n(n+1)/2 or
about n^2/2. So at 16 I would have
On Tue, Jan 29, 2008 at 10:45 AM, in message
[EMAIL PROTECTED], Gregory Stark [EMAIL PROTECTED] wrote:
Well consider when you've reached n-1 drives; the expected number of requests
before you hit the 1 idle drive remaining out of n would be n requests. When
you're at n-2 the expected number
Kevin Grittner [EMAIL PROTECTED] writes:
On Tue, Jan 29, 2008 at 9:52 AM, in message
[EMAIL PROTECTED], Gregory Stark [EMAIL PROTECTED]
wrote:
I got this from a back-of-the-envelope calculation which now that I'm trying
to reproduce it seems to be wrong. Previously I thought it was
Hello,
(Tom, sorry if you receive this letter twice. The first copy was
unintentionally sent with 'reply to sender only', I resend it to the
list, reply this one to keep the thread, please.)
2008/1/25, Tom Lane [EMAIL PROTECTED]:
Well, there's our problem: an estimate of 1
On Tue, 29 Jan 2008, Gregory Stark wrote:
This was with 8192 random requests of size 8192 bytes from an 80GB test file.
Unsorted requests ranged from 1.8 MB/s with no prefetching to 28MB/s with lots
of prefetching. Sorted requests went from 2.4MB/s to 38MB/s. That's almost
exactly 16x
Matthew Lunnon wrote:
Ahh, sorry, I have been too aggressive with my cutting, I am running
8.2.6 and the function is below.
snip
$BODY$
LANGUAGE 'sql' VOLATILE;
^^
I suspect that it's because you're using VOLATILE (so no good
optimizations is done); did you try
Thanks Euler,
I made the change to STABLE but it didn't seem to make any difference.
On closer inspection it seems to have been a casting problem, I was
passing a varchar into the function and then testing this for equality
with an integer. The planner seems to have been unable to use this
Matthew [EMAIL PROTECTED] writes:
On Tue, 4 Dec 2007, Gregory Stark wrote:
FWIW I posted some numbers from a synthetic case to pgsql-hackers
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00088.php
...
This was with 8192 random requests of size 8192 bytes from an 80GB test file.
There are several suppliers who offer Seagate's 2.5 15k rpm disks, I
know HP, Dell are amongst those. So I was actually refering to those,
rather than to the 10k one's.
Best regards,
Arjen
[EMAIL PROTECTED] wrote:
On Mon, 28 Jan 2008, Arjen van der Meijden wrote:
On 28-1-2008 20:25
Matthew Lunnon [EMAIL PROTECTED] writes:
Is there any way to work out what plan the query is using in side the
function? I think I have a similar problem with a query taking much
longer from inside a function than it does as a select statement.
Standard approach is to PREPARE a statement
On Tue, Jan 29, 2008 at 04:28:45PM +0200, Adrian Moisey wrote:
Seriously though, how do I try measure this?
Is autovacuum not going to work for your case?
A
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your
Hi
How long is a piece of string?
While we're at it, how often do I vacuum analyze?
Seriously though, how do I try measure this?
--
Adrian Moisey
System Administrator | CareerJunction | Your Future Starts Here.
Web: www.careerjunction.co.za | Email: [EMAIL PROTECTED]
Phone: +27 21 686 6820 |
Mike Smith wrote:
I’ve seen a few performance posts on using different hardware
technologies to gain improvements. Most of those comments are on raid,
interface and rotation speed. One area that doesn’t seem to have
been mentioned is to run your disks empty.
...
On the outside of the
[presumably the empty-disk effect could also be achieved by partitioning, say
25% of the drive for the database, and 75% empty partition. But in fact, you
could use that low performance 75% for rarely-used or static data, such as
the output from pg_dump, that is written during non-peak times]
On Jan 29, 2008 8:28 AM, Adrian Moisey [EMAIL PROTECTED] wrote:
Hi
How long is a piece of string?
While we're at it, how often do I vacuum analyze?
Seriously though, how do I try measure this?
1: Turn on autovacuum.
2: Look up the thread on nagios plugins for pgsql and rip the query
for
Dmitry Potapov [EMAIL PROTECTED] writes:
2008/1/25, Tom Lane [EMAIL PROTECTED]:
It's hard to tell whether the planner is just being overoptimistic
about the results of ANDing the three join conditions, or if one or
more of the basic condition selectivities were misestimated.
I wonder if it
19 matches
Mail list logo
