> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> "Rainer Mager" writes:
> >> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> >> Hmm ... it's pretty unusual to see the index fetch portion of a
> bitmap
> >> scan take the bulk of the runtime. Usually that part is fast and
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Running the latest version of Postgresql 8.2.x (I want to upgrade to
> 8.3, but the dump/reload requires an unacceptable amount of downtime)
You can use Slony or Bucardo to ugrade in place. Both will incur some
overhead and more overall compl
"Rainer Mager" writes:
>> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> Hmm ... it's pretty unusual to see the index fetch portion of a bitmap
>> scan take the bulk of the runtime. Usually that part is fast and where
>> the pain comes is in fetching from the heap. I wonder whether that
>> index
Thanks for all the replies, I'll try to address the follow up questions:
> From: David Wilson [mailto:david.t.wil...@gmail.com]
>
> The stats look good and it's using a viable index for your query. What
> kind of hardware is this on, and what are the relevant postgresql.conf
> lines? (Or, for tha
"Rainer Mager" writes:
> explain analyze select * from ad_log where date(start_time) <
> date('2009-03-31') and date(start_time) >= date('2009-03-30');
> Bitmap Heap Scan on ad_log (cost=73372.57..3699152.24 rows=2488252
> width=32) (actual time=49792.862..64611.255 rows=2268490 loops=1)
>Re
When I try to do queries on this
table I always find them slower than what I need and what I believe
should be possible.
-> Bitmap Index Scan on ad_log_date_all (cost=0.00..72750.51
rows=2488252 width=0) (actual time=49776.332..49776.332 rows=2268490
loops=1)
Index Cond: ((date(
On Sun, Apr 5, 2009 at 7:26 PM, Rainer Mager wrote:
> Bitmap Heap Scan on ad_log (cost=73372.57..3699152.24 rows=2488252
> width=32) (actual time=49792.862..64611.255 rows=2268490 loops=1)
>
> Recheck Cond: ((date(start_time) < '2009-03-31'::date) AND
> (date(start_time) >= '2009-03-30'::date)
I have a somewhat large table (more than 100 million rows) that contains log
data with start_time and end_time columns. When I try to do queries on this
table I always find them slower than what I need and what I believe should
be possible.
For example, I limited the following query to just a s
I have a high traffic database with high volumes of reads, and moderate
volumes of writes. Millions of queries a day.
Running the latest version of Postgresql 8.2.x (I want to upgrade to
8.3, but the dump/reload requires an unacceptable amount of downtime)
Server is a dual core xeon 3GB ram a
I am looking to setup replication of my postgresql database, primarily
for performance reasons.
The searching I've done shows a lot of different options, can anyone
give suggestions about which one(s) are best? I've read the archives,
but there seems to be more replication solutions since the
David Kerr writes:
> Fortunately the network throughput issue is not mine to solve.
> Would it be fair to say that with the pgbench output i've given so far
> that if all my users clicked "go" at the same time (i.e., worst case
> scenario), i could expect (from the database) about 8 second respo
Tom Lane wrote:
Simon Riggs writes:
On Fri, 2009-04-03 at 16:34 -0700, David Kerr wrote:
400 concurrent users doesn't mean that they're pulling 1.5 megs /
second every second.
There's a world of difference between 400 connected and 400 concurrent
users. You've been testing 400 concurrent us
Simon Riggs writes:
> On Fri, 2009-04-03 at 16:34 -0700, David Kerr wrote:
>> 400 concurrent users doesn't mean that they're pulling 1.5 megs /
>> second every second.
> There's a world of difference between 400 connected and 400 concurrent
> users. You've been testing 400 concurrent users, yet w
On Fri, 2009-04-03 at 16:34 -0700, David Kerr wrote:
> 400 concurrent users doesn't mean that they're pulling 1.5 megs /
> second every second. Just that they could potentially pull 1.5 megs at
> any one second. most likely there is a 6 (minimum) to 45 second
> (average) gap between each individu
14 matches
Mail list logo
