On 09/11/2011 06:44 PM, Anthony Presley wrote:
We've currently got PG 8.4.4 running on a whitebox hardware set up,
with (2) 5410 Xeon's, and 16GB of RAM. It's also got (4) 7200RPM SATA
drives, using the onboard IDE controller and ext3.
A few weeks back, we purchased two refurb'd HP DL360's G5
On 09/13/2011 03:13 PM, Samuel Gendler wrote:
Bonnie++ delivered the expected huge throughput for sequential read
and write. It seems in line with other benchmarks I found online.
However, we are only seeing 180 seeks/sec, but seems quite low.
I wouldn't worry about that if the sequential ra
On 14.09.2011 09:39, Stefan Keller wrote:
Should I open a ticket?
What ticket? With whom?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgre
On 14.09.2011 03:24, Tom Lane wrote:
The big picture though is that we're not going to remove hash indexes,
even if they're nearly useless in themselves, because hash index
opclasses provide the foundation for the system's knowledge of how to
do the datatype-specific hashing needed for hash joins
>> Hash indexes have been improved since 2005 - their performance was
>> improved quite a bit in 9.0. Here's a more recent analysis:
>
>> http://www.depesz.com/index.php/2010/06/28/should-you-use-hash-index/
>
> The big picture though is that we're not going to remove hash indexes,
> even if
here is the explain analyze output->
server=# explain analyze select count(*) from temp_by_hour where xid > 100
and xdate > now() - interval '1 week';
QUERY
PLAN
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
-postgres version -> 8.4.4
-os -> redhat 5.6
-specs ->24 cores, 96GB ram, shared_buffers=32 GB
-postgresql.conf -> i havent made any changes as far as the query tuning
parameters are concerned.
#--
# QUERY TUNING
#-
On 14 Září 2011, 15:09, MirrorX wrote:
> here is the explain analyze output->
> server=# explain analyze select count(*) from temp_by_hour where xid > 100
> and xdate > now() - interval '1 week';
> QUERY
> PLAN
> --
thx for the answer.
- What is the problem, i.e. what behaviour you expect?
- How much data is the table?
- What portion of it matches the conditions?
- What is the index definition?
i think in my first post i provided most of these details but ->
1) what i expect is to be able to understand why
14.09.11 18:14, MirrorX написав(ла):
i think in my first post i provided most of these details but ->
1) what i expect is to be able to understand why the index is not used and
if possibly to use it somehow, or recreate it in a better way
2) the table has 115 GB and about 700 milion rows
3) the r
On 14 Září 2011, 17:14, MirrorX wrote:
> thx for the answer.
>
> - What is the problem, i.e. what behaviour you expect?
> - How much data is the table?
> - What portion of it matches the conditions?
> - What is the index definition?
>
> i think in my first post i provided most of these details but
On Wed, Sep 14, 2011 at 2:44 AM, Greg Smith wrote:
> If you want to get a useful measurement of seeks/second, setup pgbench-tools
> with a SELECT-only test, and create a database that's 2 to 4X as big as RAM.
> The TPS result you get from that is a much more useful number for
> real-world seeks t
From: Carlo Stonebanks [mailto:stonec.regis...@sympatico.ca]
Sent: Tuesday, September 13, 2011 9:27 PM
To: Performance support Postgresql
Subject: Re: Migrated from 8.3 to 9.0 - need to update config (re-post)
Ok, connection pooler it is. As I underst
On Wed, Sep 14, 2011 at 03:40:07PM -0400, Igor Neyman wrote:
>
>
> From: Carlo Stonebanks [mailto:stonec.regis...@sympatico.ca]
> Sent: Tuesday, September 13, 2011 9:27 PM
> To: Performance support Postgresql
> Subject: Re: Migrated from 8.3 to 9.0 - need to update config (re-post)
>
>
>
> _
2011/9/14 Tom Lane writes:
> (...) I think that
> the current state of affairs is still what depesz said, namely that
> there might be cases where they'd be a win to use, except the lack of
> WAL support is a killer. I imagine somebody will step up and do that
> eventually.
How much of work (in
Stefan Keller writes:
> 2011/9/14 Tom Lane writes:
>> (...) I think that
>> the current state of affairs is still what depesz said, namely that
>> there might be cases where they'd be a win to use, except the lack of
>> WAL support is a killer. I imagine somebody will step up and do that
>> even
Thanks guys, So, would you say that transaction pooling has a load-balancing
effect because of its granularity compared to session pooling? I'm concerned
about the side-effects of transaction pooling, like the sessiion-level features
we would always have to look out for. Wouldn't this require
18 matches
Mail list logo
