Peter J. Holzer wrote:
> [PostgreSQL 9.5.9 on x86_64-pc-linux-gnu, compiled by gcc (Debian
> 4.9.2-10) 4.9.2, 64-bit]
>
> While investigating a performance issue, I found this query plan:
>
> wds=> explain analyze
> select facttablename, columnname, term, concept_id, t.hidden, language,
>
[PostgreSQL 9.5.9 on x86_64-pc-linux-gnu, compiled by gcc (Debian
4.9.2-10) 4.9.2, 64-bit]
While investigating a performance issue, I found this query plan:
wds=> explain analyze
select facttablename, columnname, term, concept_id, t.hidden, language,
register, c.id, canonicalname, descript
On Thu, Feb 18, 2016 at 11:05 PM, Tom Lane wrote:
> Victor Blomqvist writes:
> > We just had a major issue on our databases, after a index was replaced a
> > user defined function didnt change its query plan to use the new index.
>
> I'm suspicious that this is some variant of the problem discus
Victor Blomqvist writes:
> We just had a major issue on our databases, after a index was replaced a
> user defined function didnt change its query plan to use the new index.
I'm suspicious that this is some variant of the problem discussed a couple
days ago:
http://www.postgresql.org/message-id/
On 2/18/16, Victor Blomqvist wrote:
> Hello!
>
> We just had a major issue on our databases, after a index was replaced a
> user defined function didnt change its query plan to use the new index. At
> least this is our theory, since the function in question became much slower
> and as a result bro
The end goal is to get rid of index bloat. If there is a better way to
handle this Im all ears!
/Victor
On Thu, Feb 18, 2016 at 5:21 PM, Oleg Bartunov wrote:
>
>
> On Thu, Feb 18, 2016 at 11:17 AM, Victor Blomqvist wrote:
>
>> Hello!
>>
>> We just had a major issue on our databases, after a in
On Thu, Feb 18, 2016 at 11:17 AM, Victor Blomqvist wrote:
> Hello!
>
> We just had a major issue on our databases, after a index was replaced a
> user defined function didnt change its query plan to use the new index. At
> least this is our theory, since the function in question became much slowe
Hello!
We just had a major issue on our databases, after a index was replaced a
user defined function didnt change its query plan to use the new index. At
least this is our theory, since the function in question became much slower
and as a result brought our system to a halt.
Basically it went:
1
On Wed, 18 Sep 2013 16:24:16 +0100
Tim Kane wrote:
>
>
> On 18/09/2013 14:44, "Rowan Collins" wrote:
>
> >
> >Running an EXPLAIN on the exact query should give you the plan. An
> >EXPLAIN ANALYZE would have to wait for the query to complete either
> >way, so you wouldn't be able to get it mid
On 18/09/2013 14:44, "Rowan Collins" wrote:
>
>Running an EXPLAIN on the exact query should give you the plan. An
>EXPLAIN ANALYZE would have to wait for the query to complete either way,
>so you wouldn't be able to get it mid-way through a running process.
>
>If you don't know the exact query
François Beausoleil wrote (on 18/09/2013):
Hi!
Is it possible to get the plan of a query that's currently running? I have
queries which normally take about 15 minutes, but are now at 2+ hours. I forgot
to add the code to dump the plan to STDOUT, so I really don't know.
It might be data volume
Hi!
Is it possible to get the plan of a query that's currently running? I have
queries which normally take about 15 minutes, but are now at 2+ hours. I forgot
to add the code to dump the plan to STDOUT, so I really don't know.
It might be data volume, but I want to confirm that the plan isn't b
"Looby, Denis" writes:
> What I don't understand is why the plan is different just because the
> group_id = has changed value?
> Does the planner have some statistical info on the contents of non-indexed
> rows?
Of course. In this case it knows that a nestloop would be a loser
because many row
Hi All,
I have an interesting query scenario I'm trying to understand.
I came across this while investigating a slow query in our application.
I've been able to reproduce the scenario in a psql script that sets up the
tables and runs the queries.
Script here http://pastebin.com/CBkdDmWp if anyone
2011/2/2, Tom Lane :
>> I see the database doesn't understand that there are no entries in the
>> main table, so it has to assume the Append data is not ordered. Is
>> there a way to avoid sorting?
>
> No. In existing releases there is no plan type that can produce
> presorted output from an appe
Sergey Zaharchenko writes:
> I need to select some data in the time order. When I query a separate
> smaller table, the index is used an no sorting is needed. However,
> when I query the main table, it occurs:
> ...
> -> Sort ...
> Sort Key: ...
> Sort Method: ...
> -
Hello list,
I have a large time-indexed table (states) partitioned into several
tables based on the date. The smaller tables are clustered by their
time indices.The main table is empty.
I need to select some data in the time order. When I query a separate
smaller table, the index is used an no so
On 14/09/2010, at 10:37 AM, Yaroslav Tykhiy wrote:
On 14/09/2010, at 12:41 AM, Tom Lane wrote:
Yaroslav Tykhiy writes:
[...]
I think the major problem you're having is that the planner is
completely clueless about the selectivity of the condition
"substring"(v.headervalue, 0, 255)
Hi Tom,
On 14/09/2010, at 12:41 AM, Tom Lane wrote:
Yaroslav Tykhiy writes:
-> Bitmap Heap Scan on dbmail_headervalue v
(cost=1409.82..221813.70 rows=2805 width=16) (actual
time=28543.411..28623.623 rows=1 loops=1)
Recheck Cond: (v.headername_i
Yaroslav Tykhiy writes:
> -> Bitmap Heap Scan on dbmail_headervalue v
> (cost=1409.82..221813.70 rows=2805 width=16) (actual
> time=28543.411..28623.623 rows=1 loops=1)
> Recheck Cond: (v.headername_id = n.id)
> Fi
tliche Bindungswirkung. Aufgrund der leichten
Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den
Inhalt uebernehmen.
From: y...@barnet.com.au
To: pgsql-general@postgresql.org
Subject: [GENERAL] Query plan choice issue
Date: Mon, 13 Sep 2010 09:36:35 +1000
Hi all,
I'
entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
> From: y...@barnet.com.au
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] Query plan choice issue
> Date: Mon, 13 Sep 2010 09
Hi all,
I'm seeing a funny behaviour in Postgresql 8.4.4. Namely, a query can
be executed using either of two different query plans, one taking a
few milliseconds and the other, tens of seconds. The work_mem setting
doesn't seem to affect it -- tried to increase or decrease it by 2 or
4
Albert Vernon Smith <[EMAIL PROTECTED]> writes:
> I just re-checked, and all the same index definitions are on both
> tables.
Well, that seems to imply that the 8.0 planner is missing the plan that
7.4 finds ... which is both hard to believe and impossible to
investigate with this much info. Wo
I just re-checked, and all the same index definitions are on both
tables.
Cheers,
-albert
On 17.6.2005, at 14:20, Tom Lane wrote:
Albert Vernon Smith <[EMAIL PROTECTED]> writes:
I am in process of migrating a database from Pg 7.4.3 to Pg 8.0.3. I
dumped and reloaded the data, and things l
Albert Vernon Smith <[EMAIL PROTECTED]> writes:
> I am in process of migrating a database from Pg 7.4.3 to Pg 8.0.3. I
> dumped and reloaded the data, and things look good, until I try to
> work with it. When I try to make a query to a view based on a large
> join (select * from 'view' limi
I am in process of migrating a database from Pg 7.4.3 to Pg 8.0.3. I
dumped and reloaded the data, and things look good, until I try to
work with it. When I try to make a query to a view based on a large
join (select * from 'view' limit 10), the 7.4.3 query works very
well, and the indexe
Thanks Tom,
works, have to test performance
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 7:36 AM
To: Maksim Likharev
Cc: GENERAL
Subject: Re: [GENERAL] Query plan question
"Maksim Likharev" <[EMAIL PROTECTED]> write
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> basically I complaining that PG does not do what I told to do or
> was hoping to do.
Okay, now I get the point: you want to prevent the "pt" sub-select from
being flattened into the outer query.
7.3.1 through 7.3.3 will actually do what you want (t
"Richard Huxton" <[EMAIL PROTECTED]> writes:
> With indexed varchar fields the explain changes - performing a seq-scan on
> users rather than using the index.
> Is this because the estimator guesses costs differently for char vs varchar
> or is it because I'm not explicitly casting the id fields?
On Wed, Oct 27, 1999 at 11:03:45AM +0100, Tim Joyce wrote:
> can someone point me at documentation so that i can unserstand the results
> of an EXPLAIN, eg:
>
> Index Scan using words_id_idx on books_idx (cost=441.19 rows=7644 width=8)
>
> explain select * from books_idx where wrd_id=1;
>
> I
can someone point me at documentation so that i can unserstand the results
of an EXPLAIN, eg:
Index Scan using words_id_idx on books_idx (cost=441.19 rows=7644 width=8)
explain select * from books_idx where wrd_id=1;
I am paticularly interested in what the rows= figure means.
TIA
timj
***
32 matches
Mail list logo
