decibel wrote:
On Mar 10, 2009, at 4:12 PM, Steve McLellan wrote:
The server itself is a dual-core 3.7GHz Xeon Dell (each core reporting 2
logical CPUs) running an amd64 build of FreeBSD 6.2, and postgres
8.3.5 built
from source.
Uh, you're running an amd64 build on top of an Intel CPU? I di
On Mar 10, 2009, at 4:12 PM, Steve McLellan wrote:
The server itself is a dual-core 3.7GHz Xeon Dell (each core
reporting 2
logical CPUs) running an amd64 build of FreeBSD 6.2, and postgres
8.3.5 built
from source.
Uh, you're running an amd64 build on top of an Intel CPU? I didn't
think
On Tue, Mar 10, 2009 at 9:15 PM, Steve McLellan wrote:
> Thanks - the nested loop is indeed causing problems - reducing
> seq_page_cost had the same effect of removing the nested loop for this
> query. We'd noticed the poor row count estimation. Increasing the statistics
> doesn't seem to have muc
>
>
>
> *"Kevin Grittner" *
> 03/10/2009 05:06 PM EST
>
> > enable_seqscan = off
>
> Not a good idea; some queries will optimize better with seqscans.
> You can probably get the behavior you want using other adjustments.
>
The bullet to cure the headache, as Scott said.
>
> You probably need to re
>
>
> *Scott Marlowe *
> 03/10/2009 05:19 PM
>
> >
> > Nested Loop (cost=466.34..192962.24 rows=15329 width=12) (actual
> > time=13653.238..31332.113 rows=131466 loops=1)
>
>
> Both your query plans end with this nested loop join which is taking
> up about half your time in your query. Notice th
>
>
>
> *Tom Lane *
> Sent by: pgsql-performance-ow...@postgresql.org
> 03/10/2009 08:16 PM AST
>
> "Steve McLellan" writes:
> > lc_messages = 'en_US.UTF-8'
> > lc_monetary = 'en_US.UTF-8'
> > lc_numeric = 'en_US.UTF-8'
> > lc_time = 'en_US.UTF-8'
>
> BTW, aside from the points already made: the a
"Steve McLellan" writes:
> lc_messages = 'en_US.UTF-8'
> lc_monetary = 'en_US.UTF-8'
> lc_numeric = 'en_US.UTF-8'
> lc_time = 'en_US.UTF-8'
BTW, aside from the points already made: the above indicates that you
initialized your database in en_US.utf8 locale. This is not necessarily
a good decisio
"Kevin Grittner" writes:
> You probably need to reduce random_page_cost. If your caching is
> complete enough, you might want to set it equal to seq_page_cost
> (never set it lower that seq_page_cost!) and possibly reduce both of
> these to 0.1.
> Some people have had good luck with boosting cp
On Tue, Mar 10, 2009 at 3:12 PM, Steve McLellan wrote:
>
> Nested Loop (cost=466.34..192962.24 rows=15329 width=12) (actual
> time=13653.238..31332.113 rows=131466 loops=1)
Both your query plans end with this nested loop join which is taking
up about half your time in your query. Notice the e
>>> "Steve McLellan" wrote:
> The server itself is a dual-core 3.7GHz Xeon Dell (each core
> reporting 2 logical CPUs) running an amd64 build of FreeBSD 6.2, and
> postgres 8.3.5 built from source. It's got 400GB storage in RAID-5
> (on 5 disks). It has 8GB of physical RAM. I'm able to use about
On Tue, Mar 10, 2009 at 3:12 PM, Steve McLellan wrote:
> Hi,
>
> I'd be grateful for any advice we can get... we recently switched from MySQL
> to PostgreSQL on the basis of some trials we carried out with datasets of
> varying sizes and varying rates of contention. For the most part we've been
>
Hi,
I'd be grateful for any advice we can get... we recently switched from MySQL
to PostgreSQL on the basis of some trials we carried out with datasets of
varying sizes and varying rates of contention. For the most part we've been
pleased with performance, but one particular application runs queri
12 matches
Mail list logo
