On 11/17/09 10:58 PM, "da...@lang.hm" wrote:
>
> keep in mind that bonnie++ isn't always going to reflect your real
> performance.
>
> I have run tests on some workloads that were definantly I/O limited where
> bonnie++ results that differed by a factor of 10x made no measurable
> difference in
On 11/17/09 10:51 AM, "Greg Smith" wrote:
> Merlin Moncure wrote:
>> I am right now talking to someone on postgresql irc who is measuring
>> 15k iops from x25-e and no data loss following power plug test.
> The funny thing about Murphy is that he doesn't visit when things are
> quiet. It's quit
Scott Carey writes:
> For your database DATA disks, leaving the write cache on is 100% acceptable,
> even with power loss, and without a RAID controller. And even in high write
> environments.
Really? How hard have you tested that configuration?
> That is what the XLOG is for, isn't it?
Once
On 11/15/09 12:46 AM, "Craig Ringer" wrote:
> Possible fixes for this are:
>
> - Don't let the drive lie about cache flush operations, ie disable write
> buffering.
>
> - Give Pg some way to find out, from the drive, when particular write
> operations have actually hit disk. AFAIK there's no su
On 11/13/09 10:21 AM, "Karl Denninger" wrote:
>
> One caution for those thinking of doing this - the incremental
> improvement of this setup on PostGresql in WRITE SIGNIFICANT environment
> isn't NEARLY as impressive. Indeed the performance in THAT case for
> many workloads may only be 20 or
I found a bit of time to play with this.
I started up a test with 20 concurrent processes all inserting into
the same table and committing after each insert. The db was achieving
about 5000 inserts per second, and I kept it running for about 10
minutes. The host was doing about 5MB/s of P
In response to Waldomiro :
> I?m thinking It hapens because in the 7 millions tables, the same 8k
> block has diferent records with different keys, so only a few records
> with 'my_key' is retrieved when I read a 8k block.
> In the part_table, all records stored in a 8k block have 'my_key', so
>
Waldomiro wrote:
...
I´m thinking It hapens because in the 7 millions tables, the same 8k
block has diferent records with different keys, so only a few records
with 'my_key' is retrieved when I read a 8k block.
In the part_table, all records stored in a 8k block have 'my_key', so
It´s much opt
On Wed, 18 Nov 2009, Waldomiro wrote:
So, I need to retrieve only the last value for some key. That key has about
20.000 tuples in this table.
SELECT field1
FROM table_7milions
WHERE field1 = 'my_key'
ORDER BY field1 DESC
LIMIT 1
What's the point of this query? You are forcing Postgresql to r
Hello everbody,
I´m doing some tests with a large table about 7 milions tuples.
So, I need to retrieve only the last value for some key. That key has
about 20.000 tuples in this table.
SELECT field1
FROM table_7milions
WHERE field1 = 'my_key'
ORDER BY field1 DESC
LIMIT 1
The statistics table
On Sat, 14 Nov 2009, Tom Lane wrote:
Matthew Wakeling writes:
[ discussion about applying materialize to a mergejoin's inner indexscan ]
I have finally gotten round to doing something about this, and applied
the attached patch to CVS HEAD. Could you test it on your problem case
to see what h
usual answer - use LEFT JOIN luke.
12 matches
Mail list logo
