Re: [PERFORM] Sequential scan instead of index scan

2012-08-07 Thread Ioannis Anagnostopoulos
Offhand I'd have thought that ANALYZE would gather stats on the date_trunc expression (because it is indexed) and then you should get something reasonably accurate for a comparison to a constant. Reasonably accurate meaning not off by two orders of magnitude. Practically all of your runtime is

Re: [PERFORM] Sequential scan instead of index scan

2012-08-07 Thread Ioannis Anagnostopoulos
On 07/08/2012 17:00, Jeff Janes wrote: On Mon, Aug 6, 2012 at 8:08 AM, Ioannis Anagnostopoulos ioan...@anatec.com wrote: Hi, my query is very simple: select msg_id, msg_type, ship_pos_messages.pos_georef1, ship_pos_messages.pos_georef2

[PERFORM] Sequential scan instead of index scan

2012-08-06 Thread Ioannis Anagnostopoulos
Hi, my query is very simple: select msg_id, msg_type, ship_pos_messages.pos_georef1, ship_pos_messages.pos_georef2, ship_pos_messages.pos_georef3, ship_pos_messages.pos_georef4, obj_id, ship_speed,

Re: [PERFORM] Sequential scan instead of index scan

2012-08-06 Thread Ioannis Anagnostopoulos
or something, you might do better if the data does exhibit disk locality. If the data really is scattered, then a seq scan really will be quicker. Regards, David On 06/08/12 23:08, Ioannis Anagnostopoulos wrote: Hi, my query is very simple: select msg_id, msg_type

Re: [PERFORM] Sequential scan instead of index scan

2012-08-06 Thread Ioannis Anagnostopoulos
On 06/08/2012 16:34, Tom Lane wrote: Ioannis Anagnostopoulos ioan...@anatec.com writes: I think this is a pretty good plan and quite quick given the size of the table (88Million rows at present). However in real life the parameter where I search for msg_id

[PERFORM] Heavy inserts load wile querying...

2012-07-24 Thread Ioannis Anagnostopoulos
Hello, The Postres 9.0 database we use gets about 20K inserts per minute. As long as you don't query at the same time the database is copying fine. However long running queries seems to delay so much the db that the application server buffers the incoming data as it cannot insert them fast

Re: [PERFORM] Heavy inserts load wile querying...

2012-07-24 Thread Ioannis Anagnostopoulos
On 24/07/2012 15:30, Craig James wrote: On Tue, Jul 24, 2012 at 6:22 AM, Ioannis Anagnostopoulos ioan...@anatec.com mailto:ioan...@anatec.com wrote: Hello, The Postres 9.0 database we use gets about 20K inserts per minute. As long as you don't query at the same time the database

Re: [PERFORM] A very long running query....

2012-07-21 Thread Ioannis Anagnostopoulos
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 Anagnostopoulos Sent: Sat 7/21/2012 1:56 AM To: Tom Lane Cc: Claudio Freire; pgsql-performance@postgresql.org Subject

Re: [PERFORM] A very long running query....

2012-07-21 Thread Ioannis Anagnostopoulos
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 ioan...@anatec.com writes: On 21/07/2012 10:16, Marc Mamin wrote: isn't the first test superfluous here ? where

Re: [PERFORM] A very long running query....

2012-07-21 Thread Ioannis Anagnostopoulos
On 21/07/2012 00:10, Tom Lane wrote: Claudio Freire klaussfre...@gmail.com 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

Re: [PERFORM] A very long running query....

2012-07-21 Thread Ioannis Anagnostopoulos
On 21/07/2012 20:19, Claudio Freire wrote: On Sat, Jul 21, 2012 at 4:16 PM, Ioannis Anagnostopoulos ioan...@anatec.com 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

Re: [PERFORM] A very long running query....

2012-07-21 Thread Ioannis Anagnostopoulos
On 21/07/2012 21:11, Claudio Freire wrote: On Sat, Jul 21, 2012 at 5:10 PM, Claudio Freire klaussfre...@gmail.com wrote: ioan...@anatec.com wrote: (feed_all_y2012m07.ship_pos_messages join ais_server.ship_objects on (ship_pos_messages.obj_id = ship_objects.obj_id)) on

[PERFORM] A very long running query....

2012-07-20 Thread Ioannis Anagnostopoulos
Hello, the following query seems to take ages to get executed. However I am more than sure (as you can see from the explain analyse) that uses all the correct indexes. In general I have serious issues with joins in my database. This is a Postgres ver. 9.0 running postgis with the _int.sql

Re: [PERFORM] A very long running query....

2012-07-20 Thread Ioannis Anagnostopoulos
On 20/07/2012 22:23, Claudio Freire wrote: On Fri, Jul 20, 2012 at 6:19 PM, Ioannis Anagnostopoulos ioan...@anatec.com 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

Re: [PERFORM] A very long running query....

2012-07-20 Thread Ioannis Anagnostopoulos
On 20/07/2012 22:33, Claudio Freire wrote: On Fri, Jul 20, 2012 at 6:27 PM, Ioannis Anagnostopoulos ioan...@anatec.com wrote: On 20/07/2012 22:23, Claudio Freire wrote: On Fri, Jul 20, 2012 at 6:19 PM, Ioannis Anagnostopoulos ioan...@anatec.com wrote: - Nested Loop (cost=0.00

Re: [PERFORM] A very long running query....

2012-07-20 Thread Ioannis Anagnostopoulos
On 20/07/2012 22:33, Rosser Schwarz wrote: On Fri, Jul 20, 2012 at 2:27 PM, Ioannis Anagnostopoulos ioan...@anatec.com 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

Re: [PERFORM] A very long running query....

2012-07-20 Thread Ioannis Anagnostopoulos
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 ioan...@anatec.com wrote: On 20/07/2012 22:23, Claudio Freire wrote: Misestimated row counts... did you try running an analyze, or upping

Re: [PERFORM] A very long running query....

2012-07-20 Thread Ioannis Anagnostopoulos
On 21/07/2012 00:10, Tom Lane wrote: Claudio Freire klaussfre...@gmail.com 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