Re: [PERFORM] Execution Plan

2010-08-03 Thread Rodrigo E . De León Plicet
On Thu, Jul 22, 2010 at 11:06 PM, std pik wrote: > Hi all.. > Can any one help me? > I'd like to know how can we get the following information in > PostgreSQL: > Execution plan > The I/O physical reads and logical reads, CPU consumption, number of > DB block used, and any other information relevan

Re: [PERFORM] Testing Sandforce SSD

2010-08-03 Thread Merlin Moncure
On Tue, Aug 3, 2010 at 11:37 AM, Yeb Havinga wrote: > Yeb Havinga wrote: >> >> Hannu Krosing wrote: >>> >>> Did it fit in shared_buffers, or system cache ? >>> >> >> Database was ~5GB, server has 16GB, shared buffers was set to 1920MB. >>> >>> I first noticed this several years ago, when doing a C

Re: [PERFORM] Testing Sandforce SSD

2010-08-03 Thread Yeb Havinga
Yeb Havinga wrote: Hannu Krosing wrote: Did it fit in shared_buffers, or system cache ? Database was ~5GB, server has 16GB, shared buffers was set to 1920MB. I first noticed this several years ago, when doing a COPY to a large table with indexes took noticably longer (2-3 times longer) when

Re: [PERFORM] Testing Sandforce SSD

2010-08-03 Thread Greg Smith
Yeb Havinga wrote: Small IO size: 4 KB Maximum Small IOPS=86883 @ Small=8 and Large=0 Small IO size: 8 KB Maximum Small IOPS=48798 @ Small=11 and Large=0 Conclusion: you can write 4KB blocks almost twice as fast as 8KB ones. This is a useful observation about the effectiveness of the write

Re: [PERFORM] Testing Sandforce SSD

2010-08-03 Thread Yeb Havinga
Hannu Krosing wrote: Did it fit in shared_buffers, or system cache ? Database was ~5GB, server has 16GB, shared buffers was set to 1920MB. I first noticed this several years ago, when doing a COPY to a large table with indexes took noticably longer (2-3 times longer) when the indexes were in

Re: [PERFORM] Testing Sandforce SSD

2010-08-03 Thread Yeb Havinga
Scott Marlowe wrote: On Mon, Aug 2, 2010 at 6:07 PM, Greg Smith wrote: Josh Berkus wrote: That doesn't make much sense unless there's some special advantage to a 4K blocksize with the hardware itself. Given that pgbench is always doing tiny updates to blocks, I wouldn't be surp