Folks,
I turned on temp file logging for PostgreSQL to see if I needed to
adjust work_mem. Oddly, it's logging file usage up to 33 times per
executed query (and no, the query isn't large enough to need 33 separate
sorts).
Any idea what's going on here?
--Josh
--
Sent via pgsql-performance
On Tue, 27 Jan 2009, James Mansion wrote:
Craig Ringer wrote:
These devices would be interesting for a few uses, IMO. One is temp
table space and sort space in Pg. Another is scratch space for apps
(like Photoshop) that do their own VM management. There's also potential
Surely temp tables and
Craig Ringer wrote:
These devices would be interesting for a few uses, IMO. One is temp
table space and sort space in Pg. Another is scratch space for apps
(like Photoshop) that do their own VM management. There's also potential
Surely temp tables and sort space isn't subject to fsync and won'
On Mon, 26 Jan 2009, David Rees wrote:
And yes, the more memory you can squeeze into the machine, the better,
though you'll find that after a certain point, price starts going up
steeply. Of course, if you only have a 15GB database, once you reach
16GB of memory you've pretty much hit the point
On Mon, 26 Jan 2009, Matthew Wakeling wrote:
On Sun, 25 Jan 2009, Scott Marlowe wrote:
RAID-10 is almost always the right choice.
Agreed. Unless you don't care about the data and need the space, where RAID 0
might be useful, or if you really don't need the space, where RAID 1 might be
okay.
Jeff wrote:
If you use PITR + rsync you can create a binary snapshot of the db, so
restore time is simply how long it takes to untar / whatever it into
place. Our backup script basically does:
archive backup directory
pg_start_backup
rsync
pg_stop_backup
voila. I have 2 full copies of the d
Ron Mayer wrote:
> M. Edward (Ed) Borasky wrote:
>> At the CMG meeting I asked the disk drive engineers, "well, if the
>> drives are doing the scheduling, why does Linux go to all the trouble?"
>> Their answer was something like, "smart disk drives are a relatively
>> recent invention." But
>
> On
M. Edward (Ed) Borasky wrote:
> At the CMG meeting I asked the disk drive engineers, "well, if the
> drives are doing the scheduling, why does Linux go to all the trouble?"
> Their answer was something like, "smart disk drives are a relatively
> recent invention." But
One more reason?
I imagine th
On Mon, Jan 26, 2009 at 12:27 PM, Jeff wrote:
> I'm quite excited about the feature. I'm still on 8.2 mostly because of the
> downtime of the dump & restore. I wrote up some plans a while back on doing
> the poor-mans parallel restore, but I haven't had the time to actually do
> it.
We use slon
Greg Smith wrote:
> It's a tough time to be picking up inexpensive consumer SATA disks right
> now. Seagate's drive reliability has been falling hard the last couple
> of years, but all the WD drives I've started trying out instead have
> just awful firmware. At last they're all cheap I guess.
I
On Jan 26, 2009, at 3:00 PM, Joshua D. Drake wrote:
On Mon, 2009-01-26 at 14:58 -0500, Jeff wrote:
voila. I have 2 full copies of the db. You could even expand it a
bit
and after the rsync & friends have it fire up the instance and run
pg_dump against it for a pg_restore compatible dump "j
On Mon, Jan 26, 2009 at 11:58 AM, Jeff wrote:
> On Jan 26, 2009, at 2:42 PM, David Rees wrote:
>> Lots of people have databases much, much, bigger - I'd hate to imagine
>> have to restore from backup from one of those monsters.
>
> If you use PITR + rsync you can create a binary snapshot of the db
The technique Jeff is speaking of below is exactly how we do it,
except we use file-system snapshots vs rsync.
The problem is how slow log application is when recovering since it's
a single process, and very slow at that.
-kg
On Jan 26, 2009, at 11:58 AM, Jeff wrote:
On Jan 26, 2009, at
On Mon, 2009-01-26 at 14:58 -0500, Jeff wrote:
> voila. I have 2 full copies of the db. You could even expand it a bit
> and after the rsync & friends have it fire up the instance and run
> pg_dump against it for a pg_restore compatible dump "just in case".
>
> It takes a long time to restor
On Jan 26, 2009, at 2:42 PM, David Rees wrote:
Lots of people have databases much, much, bigger - I'd hate to imagine
have to restore from backup from one of those monsters.
If you use PITR + rsync you can create a binary snapshot of the db, so
restore time is simply how long it takes to u
On Mon, Jan 26, 2009 at 4:09 AM, Matthew Wakeling wrote:
> On Sun, 25 Jan 2009, Scott Marlowe wrote:
>>
>> More cores is more important than faster but fewer
>>
>> Again, more slower disks > fewer slower ones.
>
> Not necessarily. It depends what you are doing. If you're going to be
> running only
On Mon, 26 Jan 2009, M. Edward (Ed) Borasky wrote:
Is there a howto somewhere on disabling this on a Seagate Barracuda?
http://inferno.slug.org/cgi-bin/wiki?Western_Digital_NCQ is a good
discussion of disabling NCQ support under Linux (both in user-space and
directly in the kernel itself).
Craig Ringer wrote:
> M. Edward (Ed) Borasky wrote:
>
>> At the CMG meeting I asked the disk drive engineers, "well, if the
>> drives are doing the scheduling, why does Linux go to all the trouble?"
>
> One big reason is that Linux knows more about the relative importance of
> I/O operations than
M. Edward (Ed) Borasky wrote:
> At the CMG meeting I asked the disk drive engineers, "well, if the
> drives are doing the scheduling, why does Linux go to all the trouble?"
One big reason is that Linux knows more about the relative importance of
I/O operations than the individual drives do. Linux
Matthew Wakeling wrote:
> On Sun, 25 Jan 2009, M. Edward (Ed) Borasky wrote:
>> Actually, this isn't so much a 'pgbench' exercise as it is a source of
>> 'real-world application' data for my Linux I/O performance visualization
>> tools. I've done 'iozone' tests, though not recently. But what I'm
>>
On Mon, Jan 26, 2009 at 03:49:00PM +0100, Thomas Finneid wrote:
> Kenneth Marshall wrote:
>> It may be that the smaller index has update contention for the same
>> blocks that the larger index does not.
>
> Is that an assumption based on both indexes existing? if so I might agree,
> but if you are
Kenneth Marshall wrote:
It may be that the smaller index has update contention for the same
blocks that the larger index does not.
Is that an assumption based on both indexes existing? if so I might
agree, but if you are talking about only one index existing at a time
then could you explain w
On Mon, Jan 26, 2009 at 10:10:13AM +0100, Thomas Finneid wrote:
> Scott Marlowe wrote:
>
>> I'm guessing that you just had more data in the table or something by
>> the time you tested that, or some cron job was running in the
>> background, or some other issue, not the index.
>
> It starts from sc
On Sun, 25 Jan 2009, M. Edward (Ed) Borasky wrote:
Actually, this isn't so much a 'pgbench' exercise as it is a source of
'real-world application' data for my Linux I/O performance visualization
tools. I've done 'iozone' tests, though not recently. But what I'm
building is an I/O analysis toolset
On Sun, 25 Jan 2009, Scott Marlowe wrote:
More cores is more important than faster but fewer
Again, more slower disks > fewer slower ones.
Not necessarily. It depends what you are doing. If you're going to be
running only one database connection at a time, doing really big complex
queries, t
Scott Marlowe wrote:
I'm guessing that you just had more data in the table or something by
the time you tested that, or some cron job was running in the
background, or some other issue, not the index.
It starts from scratch and builds up. Every insert has constant time
from the first to the l
26 matches
Mail list logo
