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 ...)
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).
> I have other cases
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
On Thu, Jul 22, 2010 at 11:06 PM, std pik 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 information relevan
Hello
2010/7/23 std pik :
> 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.
> Tak
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 informati
Thanks for the advice Tom !
Setting enable_nestloop = off did improve the query a much better way
than setting enable_seqscan to off.
It does not screw the costs either (I had very odd costs with
enable_seqscan to off like this : Nested Loop
(cost=41665.30..42197.96 rows=1 width=96)
<[EMAIL PROTECTED]> writes:
> I was able to improve response time by seting enable_seqscan to off
enable_nestloop = off would probably be a saner choice, at least for
this particular query.
regards, tom lane
---(end of broadcast)---
> 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
65 loops=280)
Filter: (((idmagasin)::text = '011'::text) AND ((idoav)::text =
'PC_PLACARD'::text) AND (
autorise = 1))
-> Seq Scan on lm05_t_composition e (cost=0.00..14.82 rows=573 width=4)
(actual time=0.010..0.452 r
ows=573 loops=280)
Filter: (nb_vantaux >= 2)
-> S
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
-
[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
[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 - so
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, i
> 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_p
[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, w
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 time
[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 width=47
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, M
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
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 is
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 t
voyé : mercredi 1 février 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 o
"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 an
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 database
25 matches
Mail list logo
