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
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
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
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)
>
>
>
> _
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 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
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
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
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
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
> --
-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
#-
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
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
>> 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
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
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 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 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
18 matches
Mail list logo
