ware
to a non-striped (raid 1) volume on the new hardware. That could
explain the speed drop. Are the disks the same speed for the two
systems?
--
-- rouilj
John Rouillard System Administrator
Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111
--
S
your other queries running outside the transaction.
http://wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis
and
http://www.postgresql.org/docs/9.2/static/sql-dropindex.html
--
-- rouilj
John Rouillard System Administrator
Renesys
On Wed, May 25, 2011 at 03:19:59PM -0500, Kevin Grittner wrote:
> John Rouillard wrote:
> > On Mon, May 23, 2011 at 05:21:04PM -0500, Kevin Grittner wrote:
> >> John Rouillard wrote:
> >>
> >> > I seem to be able to provoke this error:
> >> >
On Mon, May 23, 2011 at 05:21:04PM -0500, Kevin Grittner wrote:
> John Rouillard wrote:
>
> > I seem to be able to provoke this error:
> >
> >vacuum...ERROR: invalid page header in
> > block 2128910 of relation base/16385/21476
>
>
disk wd2003; controller LSI MegaRAID SAS 9260-4i
Could it be an ext4 issue? It seems that ext4 may still be at the
bleeding edge for postgres use.
Thanks for any thoughts even if it's go to the admin list.
--
-- rouilj
John Rouillard System Administ
ops
Maybe the completion target percentage is off because of the threads?
--
-- rouilj
John Rouillard System Administrator
Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111
--
Sent via pgsql-performance mailing list (pgsql-performa
On Mon, May 16, 2011 at 12:23:13PM -0400, Jeff wrote:
> On May 16, 2011, at 9:17 AM, John Rouillard wrote:
> >However, in my case I have an 8 disk raid 10 with a read only load (in
> >this testing configuration). Shouldn't I expect more iops than a
> >single disk can
On Sat, May 14, 2011 at 12:07:02PM -0500, k...@rice.edu wrote:
> On Fri, May 13, 2011 at 09:09:41PM +0000, John Rouillard wrote:
> > I am adding pgiosim to our testing for new database hardware and I am
> > seeing something I don't quite get and I think it's becau
adata although that
seems like a lot of data
If I stop the pgiosim, the iostat drops to 0 write and reads as
expected.
So does anybody have any comments on how to test with pgiosim and how
to correlate the iostat and pgiosim outputs?
Thanks for your feedback.
--
t storage as fast as
the data is coming in. (I.E. make it a writeback with a longer delay
so it's more likely to drop data.)
Does anybody have any comments or testing methodologies that don't
involve using an actual postgres instance?
Thanks for your help.
--
tch/cursor change the steps I should take in
tuning it compared to somebody just issuing a normal select?
Thanks for any ideas.
--
-- rouilj
John Rouillard System Administrator
Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111
--
Sent via pg
eed to test your raid card batteries (nothing like having a
battery with only a 6 hour runtime when it takes you a couple of days
MTTR), can your database app survive with that low a commit rate? As
you said you ar expecting something almost 4-5x faster with 7200 rpm
disks.
--
output to make sure the bbu is enabled and the cache is turned on
for the raid array u0 or u1 ...?
--
-- rouilj
John Rouillard System Administrator
Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111
--
Sent via pgsql-performance mailing list
they are less than a 5 day capacity (failure
over a long weekend 3 days + 1-2 day(s) to fix the issue (replace
power supply, mobo etc.)).
--
-- rouilj
John Rouillard System Administrator
Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111
--
Sent v
On Mon, Apr 28, 2008 at 02:16:02PM -0400, Greg Smith wrote:
> On Mon, 28 Apr 2008, John Rouillard wrote:
>
> > 2008-04-21 11:36:43 UTC @(2761)i: LOG: checkpoints ... (27 seconds
> > apart)
> > so I changed:
> > checkpoint_segments = 30
> > checkpoint_war
On Tue, Apr 29, 2008 at 05:19:59AM +0930, Shane Ambler wrote:
> John Rouillard wrote:
>
> >We can't do this as we are backfilling a couple of months of data
> >into tables with existing data.
>
> Is this a one off data loading of historic data or an ongoing thing?
On Mon, Apr 28, 2008 at 06:53:09PM +0100, Heikki Linnakangas wrote:
> John Rouillard wrote:
> >We are running postgresql-8.1.3 under Centos 4
> You should upgrade, at least to the latest minor release of the 8.1
> series (8.1.11), as there has been a bunch of important bug and se
ns when you
re-add the index?
Does anybody have any things to check/ideas on why loading a 100Mb sql
file using psql would take 3 hours?
Thanks in advance for any ideas.
--
-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-244-9084 (cell)
603-
18 matches
Mail list logo
