Hello, thank you for your answer. I will give it a try and then I post here
the results.
In the original email I post the output of \d+ tweet, which contains the
indexes and constraints.
Best regards,
Caio
On Mon, Nov 4, 2013 at 8:59 PM, desmodemone wrote:
> Hello,
> I think you c
Hello,
I think you could try with an index on tweet table columns
"user_id, creation_time" [in this order , because the first argument is for
the equality predicate and the second with the range scan predicate, the
index tweet_user_id_creation_time_index is not ok because it has the
re
Hi Elliot, thank you for your answer.
I tried this query but it still suffer with index scan on
tweet_creation_time_index:
"Sort (cost=4899904.57..4899913.19 rows=3447 width=20) (actual
time=37560.938..37562.503 rows=1640 loops=1)"
" Sort Key: tt.tweet_id"
" Sort Method: quicksort Memory: 97k
These are the parameters I have set in postgresql.conf:
work_mem = 128MB
shared_buffers = 1GB
maintenance_work_mem = 1536MB
fsync = off
synchronous_commit = off
effective_cache_size = 2GB
The hardware is a modest one:
CPU: Intel(R) Atom(TM) CPU 230 @ 1.60GHz
RAM: 2GB
HD: 1TV 7200 RPM (WDC WD10
From: Caio Casimiro [mailto:casimiro.lis...@gmail.com]
Sent: Monday, November 04, 2013 4:10 PM
To: Igor Neyman
Cc: Jeff Janes; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Slow index scan on B-Tree index over timestamp field
Hi Neyman, thank you for your answer.
Unfortunately this quer
On 2013-11-04 16:10, Caio Casimiro wrote:
Hi Neyman, thank you for your answer.
Unfortunately this query runs almost at the same time:
Sort (cost=4877693.98..4877702.60 rows=3449 width=20) (actual
time=25820.291..25821.845 rows=1640 loops=1)
Sort Key: tt.tweet_id
Sort Method: quicksort
Hi Neyman, thank you for your answer.
Unfortunately this query runs almost at the same time:
Sort (cost=4877693.98..4877702.60 rows=3449 width=20) (actual
time=25820.291..25821.845 rows=1640 loops=1)
Sort Key: tt.tweet_id
Sort Method: quicksort Memory: 97kB
Buffers: shared hit=1849 read=3
From: pgsql-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Caio Casimiro
Sent: Monday, November 04, 2013 3:44 PM
To: Jeff Janes
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Slow index scan on B-Tree index over timestamp field
Thank y
I should also say that table tweet has more than 400 millions hows and
table tweet_topic has estimated more than 800 millions rows.
Thanks again,
Caio
On Mon, Nov 4, 2013 at 6:44 PM, Caio Casimiro wrote:
> Thank you very much for your answers guys!
>
>
> On Mon, Nov 4, 2013 at 5:15 PM, Jeff Jan
Thank you very much for your answers guys!
On Mon, Nov 4, 2013 at 5:15 PM, Jeff Janes wrote:
> On Sun, Nov 3, 2013 at 2:05 PM, Caio Casimiro
> wrote:
>
>> Hello all,
>>
>> I have one query running at ~ 7 seconds and I would like to know if it's
>> possible to make it run faster, once this que
On Sun, Nov 3, 2013 at 2:05 PM, Caio Casimiro wrote:
> Hello all,
>
> I have one query running at ~ 7 seconds and I would like to know if it's
> possible to make it run faster, once this query runs lots of time in my
> experiment.
>
Do you mean you want it to be fast because it runs many times,
On 2013-11-04 13:56, Kevin Grittner wrote:
Caio Casimiro wrote:
I have one query running at ~ 7 seconds and I would like to know
if it's possible to make it run faster, once this query runs lots
of time in my experiment.
Buffers: shared hit=2390 read=32778
Total runtime: 24066.145 ms
effec
Caio Casimiro wrote:
> I have one query running at ~ 7 seconds and I would like to know
> if it's possible to make it run faster, once this query runs lots
> of time in my experiment.
> Buffers: shared hit=2390 read=32778
> Total runtime: 24066.145 ms
> effective_cache_size = 2GB
> it seems
13 matches
Mail list logo
