"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 w
[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 quer
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
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 statemen
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 t
>>> 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 expect
"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
>>> 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 wou
"Matthew" <[EMAIL PROTECTED]> writes:
> 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
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
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 improvement
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 dis
On Jan 29, 2008 5:43 AM, Mike Smith <[EMAIL PROTECTED]> wrote:
>
> 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 com
"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 te
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 | M
Matthew Lunnon wrote:
Ahh, sorry, I have been too aggressive with my cutting, I am running
8.2.6 and the function is below.
$BODY$
LANGUAGE 'sql' VOLATILE;
^^
I suspect that it's because you're using VOLATILE (so no good
optimizations is done); did you try STABL
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 doesn
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 Christ
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:
> 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 th
21 matches
Mail list logo
