On 21/07/2012 21:11, Claudio Freire wrote:
On Sat, Jul 21, 2012 at 5:10 PM, Claudio Freire wrote:
wrote:
(feed_all_y2012m07.ship_pos_messages join
ais_server.ship_objects on (ship_pos_messages.obj_id = ship_objects.obj_id))
on (message_copies.msg_id = ship_pos_messag
On Sat, Jul 21, 2012 at 5:10 PM, Claudio Freire wrote:
> wrote:
>> (feed_all_y2012m07.ship_pos_messages join
>> ais_server.ship_objects on (ship_pos_messages.obj_id = ship_objects.obj_id))
>> on (message_copies.msg_id = ship_pos_messages.msg_id)
>
> It's this part of the q
On Fri, Jul 20, 2012 at 6:19 PM, Ioannis Anagnostopoulos
wrote:
> (feed_all_y2012m07.ship_pos_messages join
> ais_server.ship_objects on (ship_pos_messages.obj_id = ship_objects.obj_id))
> on (message_copies.msg_id = ship_pos_messages.msg_id)
It's this part of the query th
On 21/07/2012 20:19, Claudio Freire wrote:
On Sat, Jul 21, 2012 at 4:16 PM, Ioannis Anagnostopoulos
wrote:
I am not sure that I can see an improvement, at least on src_id that have
lots of msg_id per day the query never returned even 5 hours later running
"exaplain analyze". For smaller src_id
On Sat, Jul 21, 2012 at 4:16 PM, Ioannis Anagnostopoulos
wrote:
> I am not sure that I can see an improvement, at least on src_id that have
> lots of msg_id per day the query never returned even 5 hours later running
> "exaplain analyze". For smaller src_id
> (message wise) there might be some imp
On 21/07/2012 00:10, Tom Lane wrote:
Claudio Freire writes:
Looking at this:
"-> Index Scan using
idx_message_copies_wk2_date_src_pos_partial on message_copies_wk2
message_copies (cost=0.00..19057.93 rows=52 width=32) (actual
time=62.124..5486270.845 rows=387524 loops=1)"
On 21/07/2012 17:58, Tom Lane wrote:
[ Please try to trim quotes when replying. People don't want to re-read
the entire thread in every message. ]
Ioannis Anagnostopoulos writes:
On 21/07/2012 10:16, Marc Mamin wrote:
isn't the first test superfluous here ?
where extract('day' from mess
[ Please try to trim quotes when replying. People don't want to re-read
the entire thread in every message. ]
Ioannis Anagnostopoulos writes:
> On 21/07/2012 10:16, Marc Mamin wrote:
>> isn't the first test superfluous here ?
>>
>>> where extract('day' from message_copies.msg_date_rec) = 17
>
On 21/07/2012 10:16, Marc Mamin wrote:
RE: [PERFORM] A very long running query
Hello,
isn't the first test superfluous here ?
> where extract('day' from message_copies.msg_date_rec) = 17
> and date_trunc('day', message_copies.msg_date_rec) = &#x
to concatenate the georef
within the index, but keep them separated, or even keep them in different
indexes.
Which is the best depend on the other queries running against this table
HTH,
Marc Mamin
-Original Message-
From: pgsql-performance-ow...@postgresql.org on behalf of Ioannis
An
On 07/21/2012 06:19 AM, Ioannis Anagnostopoulos wrote:
On this Ubuntu installation the default_statistics_target = 1000 and
not 100. Do you think that this might be an issue?
Nope. You should generally avoid setting default_statistics_target too
high anyway; leave it where it is and use ALTER
On 21/07/2012 00:10, Tom Lane wrote:
Claudio Freire writes:
Looking at this:
"-> Index Scan using
idx_message_copies_wk2_date_src_pos_partial on message_copies_wk2
message_copies (cost=0.00..19057.93 rows=52 width=32) (actual
time=62.124..5486270.845 rows=387524 loops=1)"
Claudio Freire writes:
> Looking at this:
> "-> Index Scan using
> idx_message_copies_wk2_date_src_pos_partial on message_copies_wk2
> message_copies (cost=0.00..19057.93 rows=52 width=32) (actual
> time=62.124..5486270.845 rows=387524 loops=1)"
> "
On 20/07/2012 22:53, Ioannis Anagnostopoulos wrote:
On 20/07/2012 22:33, Rosser Schwarz wrote:
On Fri, Jul 20, 2012 at 2:27 PM, Ioannis Anagnostopoulos
wrote:
On 20/07/2012 22:23, Claudio Freire wrote:
Misestimated row counts... did you try running an analyze, or upping
statistic targets?
I h
On 20/07/2012 22:33, Rosser Schwarz wrote:
On Fri, Jul 20, 2012 at 2:27 PM, Ioannis Anagnostopoulos
wrote:
On 20/07/2012 22:23, Claudio Freire wrote:
Misestimated row counts... did you try running an analyze, or upping
statistic targets?
I have run analyse every so often. I think the problem
On 20/07/2012 22:33, Claudio Freire wrote:
On Fri, Jul 20, 2012 at 6:27 PM, Ioannis Anagnostopoulos
wrote:
On 20/07/2012 22:23, Claudio Freire wrote:
On Fri, Jul 20, 2012 at 6:19 PM, Ioannis Anagnostopoulos
wrote:
"-> Nested Loop (cost=0.00..20942.93 rows=53 width=144) (actual
time
On Fri, Jul 20, 2012 at 6:27 PM, Ioannis Anagnostopoulos
wrote:
> On 20/07/2012 22:23, Claudio Freire wrote:
>>
>> On Fri, Jul 20, 2012 at 6:19 PM, Ioannis Anagnostopoulos
>> wrote:
>>>
>>> "-> Nested Loop (cost=0.00..20942.93 rows=53 width=144) (actual
>>> time=62.174..17783236.718 row
On Fri, Jul 20, 2012 at 2:27 PM, Ioannis Anagnostopoulos
wrote:
> On 20/07/2012 22:23, Claudio Freire wrote:
>> Misestimated row counts... did you try running an analyze, or upping
>> statistic targets?
> I have run analyse every so often. I think the problem is that as I get 16K
> new rows every
On 20/07/2012 22:23, Claudio Freire wrote:
On Fri, Jul 20, 2012 at 6:19 PM, Ioannis Anagnostopoulos
wrote:
"-> Nested Loop (cost=0.00..20942.93 rows=53 width=144) (actual
time=62.174..17783236.718 rows=387105 loops=1)"
" Join Filter: (feed_all_y2012m07.message_copies.msg_
On Fri, Jul 20, 2012 at 6:19 PM, Ioannis Anagnostopoulos
wrote:
> "-> Nested Loop (cost=0.00..20942.93 rows=53 width=144) (actual
> time=62.174..17783236.718 rows=387105 loops=1)"
> " Join Filter: (feed_all_y2012m07.message_copies.msg_id =
> feed_all_y2012m07.ship_pos_messag
20 matches
Mail list logo
