Scott Marlowe wrote:
On Tue, Mar 24, 2009 at 7:09 PM, Mark Kirkwood wrote:
I'm trying to pin down some performance issues with a machine where I work,
we are seeing (read only) query response times blow out by an order of
magnitude or more at busy times. Initially we blamed autovacuum, but a
On Tue, Mar 24, 2009 at 9:30 PM, Josh Berkus wrote:
> For some reason, your first post didn't make it to the list, which is why
> nobody responded.
Weird... I've been having problems with gmail and google reader all week.
>>> I've got a query on our production system that isn't choosing a good
>
On Tue, Mar 24, 2009 at 10:04 PM, marcin mank wrote:
> There is one thing I don`t understand:
>
> -> Nested Loop (cost=0.00..180564.28 rows=1806
> width=37) (actual time=0.192..60.214 rows=3174 loops=1)
> -> Index Scan using visitors_userid_index2 on
> visitors v
On Tue, 24 Mar 2009, David Rees wrote:
I would tend to recommend ext3 in data=writeback and make sure that
it's mounted with noatime over using ext2 - for the sole reason that
if the system shuts down unexpectedly, you don't have to worry about a
long fsck when bringing it back up.
Well, Mark'
There is one thing I don`t understand:
-> Nested Loop (cost=0.00..180564.28 rows=1806
width=37) (actual time=0.192..60.214 rows=3174 loops=1)
-> Index Scan using visitors_userid_index2 on
visitors v (cost=0.00..2580.97 rows=1300 width=33) (actual
time=0.052..2
Brian,
I hate to nag, but could anybody help me with this? We have a few
related queries that are causing noticeable service delays in our
production system. I've tried a number of different things, but I'm
running out of ideas and don't know what to do next.
For some reason, your first post
On Tue, Mar 24, 2009 at 7:09 PM, Mark Kirkwood wrote:
> I'm trying to pin down some performance issues with a machine where I work,
> we are seeing (read only) query response times blow out by an order of
> magnitude or more at busy times. Initially we blamed autovacuum, but after a
> tweak of th
On Tue, Mar 24, 2009 at 6:48 PM, Scott Carey wrote:
> Your xlogs are occasionally close to max usage too -- which is suspicious at
> 10MB/sec. There is no reason for them to be on ext3 since they are a
> transaction log that syncs writes so file system journaling doesn't mean
> anything. Ext2 th
On 3/24/09 6:09 PM, "Mark Kirkwood" wrote:
> I'm trying to pin down some performance issues with a machine where I
> work, we are seeing (read only) query response times blow out by an
> order of magnitude or more at busy times. Initially we blamed
> autovacuum, but after a tweak of the cost_de
I'm trying to pin down some performance issues with a machine where I
work, we are seeing (read only) query response times blow out by an
order of magnitude or more at busy times. Initially we blamed
autovacuum, but after a tweak of the cost_delay it is *not* the
problem. Then I looked at chec
On 3/24/09 4:16 PM, "Scott Marlowe" wrote:
> On Tue, Mar 24, 2009 at 4:58 PM, Ron wrote:
>> At 02:47 PM 3/24/2009, Joe Uhl wrote:
>>
>>> Turns out we may have an opportunity to purchase a new database server
>>> with this increased load. Seems that the best route, based on feedback to
>>> thi
On Tue, Mar 24, 2009 at 4:58 PM, Ron wrote:
> At 02:47 PM 3/24/2009, Joe Uhl wrote:
>
>> Turns out we may have an opportunity to purchase a new database server
>> with this increased load. Seems that the best route, based on feedback to
>> this thread, is to go whitebox, get quad opterons, and ge
At 02:47 PM 3/24/2009, Joe Uhl wrote:
Turns out we may have an opportunity to purchase a new database
server with this increased load. Seems that the best route, based
on feedback to this thread, is to go whitebox, get quad opterons,
and get a very good disk controller.
Can anyone recommend
I hate to nag, but could anybody help me with this? We have a few
related queries that are causing noticeable service delays in our
production system. I've tried a number of different things, but I'm
running out of ideas and don't know what to do next.
Thanks,
Bryan
On Mon, Mar 23, 2009 at 2:03
I hate to nag, but could anybody help me with this? We have a few
related queries that are causing noticeable service delays in our
production system. I've tried a number of different things, but I'm
running out of ideas and don't know what to do next.
Thanks,
Bryan
On Mon, Mar 23, 2009 at 2:03
On Tue, Mar 24, 2009 at 1:29 PM, Greg Smith wrote:
> On Tue, 24 Mar 2009, Joe Uhl wrote:
>
>> Can anyone recommend a whitebox vendor?
>
> I dumped a list of recommended vendors from a discussion here a while back
> at http://wiki.postgresql.org/wiki/SCSI_vs._IDE/SATA_Disks you could get
> started
On Tue, 24 Mar 2009, Joe Uhl wrote:
Can anyone recommend a whitebox vendor?
I dumped a list of recommended vendors from a discussion here a while back
at http://wiki.postgresql.org/wiki/SCSI_vs._IDE/SATA_Disks you could get
started with.
--
* Greg Smith gsm...@gregsmith.com http://www.greg
On Mar 20, 2009, at 4:58 PM, Scott Marlowe wrote:
On Fri, Mar 20, 2009 at 2:49 PM, Joe Uhl wrote:
On Mar 20, 2009, at 4:29 PM, Scott Marlowe wrote:
What does the cs entry on vmstat say at this time? If you're cs is
skyrocketing then you're getting a context switch storm, which is
usually
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I think a reasonable solution for this might be to keep an eye on
>> maxdepth and force a flush if that gets too large (more than a few
>> hundred, perhaps?). Something like this:
> I fooled around with a balanced tree, which solved the problem but
Tom Lane wrote:
Sergey Burladyan writes:
show maintenance_work_mem ;
maintenance_work_mem
--
128MB
create table a (i1 int, i2 int, i3 int, i4 int, i5 int, i6 int);
insert into a select n, n, n, n, n, n from generate_series(1, 10) as n;
create index arr_gin on a usin
Now I am experiencing similar issue with another table, called
"message", for which there's a conditional index:
CREATE TABLE message (
message_sid SERIAL PRIMARY KEY,
from_profile_sid INT NOT NULL REFERENCES profile,
to_profile_sid INT NOT NULL REFERENCES profile,
sender_has_deleted BOO
21 matches
Mail list logo
