Re: [GENERAL] (VERY) Slow Query - PostgreSQL 9.2

From: drum.lu...@gmail.com Sent: Tuesday, May 03, 2016 2:55 AM I'm trying to get the query below a better performance.. but just don't know what else I can do... Please, have a look and let me know if you can help somehow.. also.. if you need some extra data

Re: [GENERAL] (VERY) Slow Query - PostgreSQL 9.2

> On 03 May 2016, at 11:55, drum.lu...@gmail.com wrote: > > Hi all, > > I'm trying to get the query below a better performance.. but just don't know > what else I can do... > > Please, have a look and let me know if you can help somehow.. also.. if you > need some extra data jet ask me

Re: [GENERAL] (VERY) Slow Query - PostgreSQL 9.2

On Tue, 3 May 2016 21:55:21 +1200 "drum.lu...@gmail.com" wrote: > Hi all, > > I'm trying to get the query below a better performance.. but just don't > know what else I can do... > > Please, have a look and let me know if you can help somehow.. also.. if you > need some

[GENERAL] (VERY) Slow Query - PostgreSQL 9.2

Hi all, I'm trying to get the query below a better performance.. but just don't know what else I can do... Please, have a look and let me know if you can help somehow.. also.. if you need some extra data jet ask me please. * Note that the gorfs.inode_segments table is 1.7TB size I have the

[GENERAL] Very slow query in PostgreSQL 9.3.3

PostgreSQL 9.3.3 RHEL 6.4Total db Server memory 64GB# -# PostgreSQL configuration file# -max_connections = 100shared_buffers = 16GBwork_mem = 32MB maintenance_work_mem = 1GBseq_page_cost = 1.0 random_page_cost = 2.0 cpu_tuple_cost = 0.03

Re: [GENERAL] very slow query

am Wed, dem 12.12.2007, um 11:44:58 + mailte Ashish Karalkar folgendes: Hi, I am having PostgreSQL 8.2.4 on Suse 10.3 Server is not using the index insted it chooses to take seq scan path. table is having @ 120 million rows here is the output from planner: Nested Loop IN Join

[GENERAL] very slow query

Hi, I am having PostgreSQL 8.2.4 on Suse 10.3 Server is not using the index insted it chooses to take seq scan path. table is having @ 120 million rows here is the output from planner: Nested Loop IN Join (cost=0.00..5030217.97 rows=2 width=106) - Seq Scan on sms_new

Re: [GENERAL] very slow query

am Wed, dem 12.12.2007, um 12:25:20 + mailte Ashish Karalkar folgendes: here is the output from planner: Nested Loop IN Join (cost=0.00..5030217.97 rows=2 width=106) - Seq Scan on sms_new (cost=0.00..5027902.00 rows=384 width=106) Filter: (mobile =

Re: [GENERAL] very slow query

A. Kretschmer [EMAIL PROTECTED] wrote: am Wed, dem 12.12.2007, um 12:44:09 + mailte Ashish Karalkar folgendes: Do you have an index on mobile? Can you show us the table definition and the output from EXPLAIN ANALYSE? no index on mobile Seq Scan on sms_new ...

Re: [GENERAL] very slow query

Ashish Karalkar wrote: Thanks for your answer actually that was the part of full query here is the actuall plan I think you are confusing this for here is a completely different plan for a completely different query that has nothing to do whatsoever to what I was asking before. On this

Re: [GENERAL] very slow query

am Wed, dem 12.12.2007, um 12:44:09 + mailte Ashish Karalkar folgendes: Do you have an index on mobile? Can you show us the table definition and the output from EXPLAIN ANALYSE? no index on mobile Seq Scan on sms_new ... Filter: (mobile = 919820920858::bigint)

Re: [GENERAL] very slow query

Alvaro Herrera [EMAIL PROTECTED] wrote: Ashish Karalkar wrote: Thanks for your answer actually that was the part of full query here is the actuall plan I think you are confusing this for here is a completely different plan for a completely different query that has nothing to do whatsoever

Re: [GENERAL] very slow query

Alvaro Herrera [EMAIL PROTECTED] wrote: Ashish Karalkar wrote: Thanks for your answer actually that was the part of full query here is the actuall plan I think you are confusing this for here is a completely different plan for a completely different query that has nothing to do whatsoever

Re: [GENERAL] very slow query

A. Kretschmer [EMAIL PROTECTED] wrote: am Wed, dem 12.12.2007, um 12:25:20 + mailte Ashish Karalkar folgendes: here is the output from planner: Nested Loop IN Join (cost=0.00..5030217.97 rows=2 width=106) - Seq Scan on sms_new (cost=0.00..5027902.00 rows=384 width=106)

Re: [GENERAL] very slow query

A. Kretschmer [EMAIL PROTECTED] wrote: am Wed, dem 12.12.2007, um 11:44:58 + mailte Ashish Karalkar folgendes: Hi, I am having PostgreSQL 8.2.4 on Suse 10.3 Server is not using the index insted it chooses to take seq scan path. table is having @ 120 million rows here is the

Re: [GENERAL] very slow query

On Dec 12, 2007 5:44 AM, Ashish Karalkar [EMAIL PROTECTED] wrote: Hi, I am having PostgreSQL 8.2.4 on Suse 10.3 Server is not using the index insted it chooses to take seq scan path. table is having @ 120 million rows here is the output from planner: Nested Loop IN Join

Re: [GENERAL] Very slow query

Sorry for replying to my own post, but I'm anxious for an answer. Should I provide other information? Thanks Rory On 10/05/04, Rory Campbell-Lange ([EMAIL PROTECTED]) wrote: The following query on some small datasets takes over a second to run. I'd be grateful for some help in understanding

Re: [GENERAL] Very slow query

[snip] Rory Campbell-Lange wrote: SELECT DISTINCT b.n_id as id, b.n_type, CASE b.n_type WHEN 0 THEN 'personal' WHEN 1 THEN 'private' WHEN 2 THEN 'blog' ELSE 'public'

Re: [GENERAL] Very slow query - why?

Looking at your query, I notice that the longer query happens when you search on b.zcustnum=30538 while the LEFT OUTER JOIN remains the same. It could be that when testing a.zcustnum=30530 the server can short circuit the logic - it only has to check a.zcustnum to see if the entire tuple

Re: [GENERAL] Very slow query - why?

Richard Schilling [EMAIL PROTECTED] writes: Looking at your query, I notice that the longer query happens when you search on b.zcustnum=30538 while the LEFT OUTER JOIN remains the same. It could be that when testing a.zcustnum=30530 the server can short circuit the logic - it only has to

[GENERAL] Very slow query, Help please!

Hi ! Help me please to resolv my problem. I have two tables . One of them is large (say 10 records) with unique index on "ID" and the second table (5000 records ) which i have to insert into the first table , but the second table have much records, which have many duplicate values in "ID" .

RE: [GENERAL] Very slow query, Help please!

- From: Igor [SMTP:[EMAIL PROTECTED]] Sent: Saturday, April 14, 2001 12:33 AM To: [EMAIL PROTECTED] Subject:[GENERAL] Very slow query, Help please! Hi ! Help me please to resolv my problem. I have two tables . One of them is large (say 10 records) with unique index on &qu