Re: [PERFORM] Execution plan analysis

Hi, So looking at the plans, essentially the only part that is different is the scan node at the very bottom - in one case it's a sequential scan, in the other case (the slow one) it's the bitmap index scan. Essentially it's this: -> Seq Scan on lineitem (cost=0.00..2624738.17 ...)

Re: [PERFORM] Execution plan analysis

2017-08-25 5:31 GMT-03:00 Neto pr : > Dear all > > Someone help me analyze the execution plans below, is the query 12 of > TPC-H benchmark [1]. > I need to find out why the query without index runs faster (7 times) > than with index, although the costs are smaller (see table).

[PERFORM] Execution plan analysis

Dear all Someone help me analyze the execution plans below, is the query 12 of TPC-H benchmark [1]. I need to find out why the query without index runs faster (7 times) than with index, although the costs are smaller (see table). I have other cases that happened in the same situation. The server

Re: [PERFORM] Execution Plan

On Thu, Jul 22, 2010 at 11:06 PM, std pik std...@gmail.com wrote: Hi all.. Can any one help me? I'd like to know how can we get the following information in PostgreSQL: Execution plan The I/O physical reads and logical reads, CPU consumption, number of DB block used, and any other

[PERFORM] Execution Plan

Hi all.. Can any one help me? I'd like to know how can we get the following information in PostgreSQL: Execution plan The I/O physical reads and logical reads, CPU consumption, number of DB block used, and any other information relevant to performance. Taking into consideration that these

Re: [PERFORM] Execution Plan

Hello 2010/7/23 std pik std...@gmail.com: Hi all.. Can any one help me? I'd like to know how can we get the following information in PostgreSQL: Execution plan The I/O physical reads and logical reads, CPU consumption, number of DB block used, and any other information relevant to

[PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

Hello, I have upgraded from 7.3.9 to 8.2.3 and now the application that is using Postgres is really slow. Using pgfouine, I was able to identify a SQL select statement that was running in 500 ms before and now that is running in more than 20 seconds ! The reason is that the execution plan

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

On Tue, Mar 13, 2007 at 09:19:47AM +0100, [EMAIL PROTECTED] wrote: Is there an option in the 8.2.3 to change in order to have the same execution plan than before ? Let's see if we can figure out why 8.2.3 is choosing a bad plan. Have you run ANALYZE on the tables in 8.2.3? Could you post the

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

I have attached the requested information. You will see that the query is quite messy and could be easily improved. Unfortunately, it came from a third party application and we do not have access to the source code. Thanks for your help, Best Regards, Vincent Michael Fuhr wrote: On Tue,

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

[EMAIL PROTECTED] wrote: I have attached the requested information. You will see that the query is quite messy and could be easily improved. Unfortunately, it came from a third party application and we do not have access to the source code. - Hash Join (cost=6.31..3056.17 rows=116

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

Thanks for the update. The following did not change anything in the execution plan ALTER TABLE lm05_t_tarif_panneau ALTER COLUMN lrg_min SET STATISTICS 1000 ALTER TABLE lm05_t_tarif_panneau ALTER COLUMN lrg_max SET STATISTICS 1000 ANALYZE lm05_t_tarif_panneau I was able to improve response

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

[EMAIL PROTECTED] wrote: I have attached the requested information. You will see that the query is quite messy and could be easily improved. Unfortunately, it came from a third party application and we do not have access to the source code. There are only nested loops and hash joins, while

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Subject: Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3 The following did not change anything in the execution plan ALTER TABLE lm05_t_tarif_panneau ALTER COLUMN lrg_min SET

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

Here it is : CCM=# SHOW enable_mergejoin; enable_mergejoin -- on (1 row) CCM=# Alvaro Herrera wrote: [EMAIL PROTECTED] wrote: I have attached the requested information. You will see that the query is quite messy and could be easily improved. Unfortunately, it came

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

[EMAIL PROTECTED] wrote: Thanks for the update. The following did not change anything in the execution plan ALTER TABLE lm05_t_tarif_panneau ALTER COLUMN lrg_min SET STATISTICS 1000 ALTER TABLE lm05_t_tarif_panneau ALTER COLUMN lrg_max SET STATISTICS 1000 ANALYZE lm05_t_tarif_panneau Hmm -

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

[EMAIL PROTECTED] wrote: Here it is : CCM=# SHOW enable_mergejoin; enable_mergejoin -- on (1 row) Sorry, my question was more general. Do you have _any_ of the planner types disabled? Try also enable_indexscan, etc; maybe select * from pg_settings where name like

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

All planner types were enabled. CCM=# select * from pg_settings where name like 'enable_%'; name| setting | unit | category | short_desc | extra_desc | context | vartype | source | min_val | max_val

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Subject: Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3 The following did not change anything in the execution plan ALTER TABLE lm05_t_tarif_panneau ALTER COLUMN lrg_min SET STATISTICS 1000 ALTER

Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Subject: Re: [PERFORM] Execution plan changed after upgrade from 7.3.9 to 8.2.3 Increasing the default_statistics_target to 1000 did not help. It just make the vacuum full analyze to take longer

Re: [PERFORM] execution plan : Oracle vs PostgreSQL

Indeed there is: you can use an ARRAY constructor with SELECT. Here's some PGPLSQL code I have (simplified and with the variable names shrouded). SELECT INTO m ARRAY(SELECT d FROM hp WHERE hp.ss=$1 ORDER BY 1); FERREIRA, William (VALTECH) wrote: maybe

[PERFORM] execution plan : Oracle vs PostgreSQL

hi, i have a database storing XML documents. The main table contains the nodes of the document, the other tables contain data for each node (depending on the node's type : ELE, Text, PI, ...) My test document has 115000 nodes. the export of the document(extracting all informations from

Re: [PERFORM] execution plan : Oracle vs PostgreSQL

FERREIRA, William (VALTECH) [EMAIL PROTECTED] writes: My test document has 115000 nodes. the export of the document(extracting all informations from database and writing XML file on disk) takes 30s with Oracle and 5mn with Postgresql. The Oracle stored procedure is written in pl/sql and the

Re: [PERFORM] execution plan : Oracle vs PostgreSQL

2006 17:05 À : FERREIRA, William (VALTECH) Cc : pgsql-performance@postgresql.org Objet : Re: [PERFORM] execution plan : Oracle vs PostgreSQL FERREIRA, William (VALTECH) [EMAIL PROTECTED] writes: My test document has 115000 nodes. the export of the document(extracting all informations from