Hello, i have a problem with planning time, I do not understand why this can
happen.
PostgreSQL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc-4.4.real
(Debian 4.4.5-8) 4.4.5, 64-bit
# explain
# select i.item_id, u.user_id from items i
# left join users u on u.user_id = i.user_id
# where
Le 01/08/2013 11:55, Sergey Burladyan a écrit :
Hello, i have a problem with planning time, I do not understand why this
can happen.
PostgreSQL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc-4.4.real
(Debian 4.4.5-8) 4.4.5, 64-bit
# explain
# select i.item_id, u.user_id from items i
01.08.2013 14:05 пользователь Thomas Reiss thomas.re...@dalibo.com
написал:
If you leave enable_mergejoin to on, what happens if you run the explain
two time in a row ? Do you get the same planning time ?
Yes, I get the same planning time.
On Thu, Aug 1, 2013 at 2:04 PM, Thomas Reiss thomas.re...@dalibo.comwrote:
Le 01/08/2013 11:55, Sergey Burladyan a écrit :
At first look, this reminds me some catalog bloat issue. Can you provide
the result of these queries :
SELECT pg_size_pretty(pg_table_size('pg_class')) AS size_pg_class;
I find another query with big planning time:
explain select * from xview.user_items_v v where ( v.item_id = 132358330 );
QUERY PLAN
Sergey Burladyan eshkin...@gmail.com writes:
# explain
# select i.item_id, u.user_id from items i
# left join users u on u.user_id = i.user_id
# where item_id = 169946840;
QUERY PLAN
--
Nested Loop
On Thu, Aug 01, 2013 at 07:17:27PM +0400, Sergey Burladyan wrote:
- Sergey Burladyan eshkin...@gmail.com writes:
-
- # explain
- # select i.item_id, u.user_id from items i
- # left join users u on u.user_id = i.user_id
- # where item_id = 169946840;
- QUERY PLAN
-
Amit, All:
So we just retested this on 9.3b2. The performance is the same as 9.1
and 9.2; that is, progressively worse as the test cycles go on, and
unacceptably slow compared to 8.4.
Some issue introduced in 9.1 is causing BINDs to get progressively
slower as the PARSEs BINDs get run
On Thu, Aug 1, 2013 at 8:17 AM, Sergey Burladyan eshkin...@gmail.com wrote:
Sergey Burladyan eshkin...@gmail.com writes:
# explain
# select i.item_id, u.user_id from items i
# left join users u on u.user_id = i.user_id
# where item_id = 169946840;
QUERY PLAN
Jeff Janes jeff.ja...@gmail.com writes:
I'd use strace to find what file handle is being read and written, and
lsof to figure out what file that is.
I use strace, it is more read then write:
$ cut -d '(' -f 1 /var/tmp/pg.trace | sort | uniq -c | sort -n
49 select
708 close
1021
On Thu, Aug 1, 2013 at 10:58 AM, Josh Berkus j...@agliodbs.com wrote:
Amit, All:
So we just retested this on 9.3b2. The performance is the same as 9.1
and 9.2; that is, progressively worse as the test cycles go on, and
unacceptably slow compared to 8.4.
Some issue introduced in 9.1 is
Howdy. I seem to have inherited this problem:
http://www.postgresql.org/message-id/ef524e81-b815-4122-a337-7e50bced5...@silentmedia.com
Basically a subselect with no offset is resulting in really poor
performance with 120s queries but adding an offset 0 to the inner sub
select results in 0.5s
On Thu, Aug 1, 2013 at 12:13 PM, Sergey Burladyan eshkin...@gmail.com wrote:
Jeff Janes jeff.ja...@gmail.com writes:
I'd use strace to find what file handle is being read and written, and
lsof to figure out what file that is.
I use strace, it is more read then write:
$ cut -d '(' -f 1
On Thu, Aug 1, 2013 at 2:40 PM, Scott Marlowe scott.marl...@gmail.com wrote:
Howdy. I seem to have inherited this problem:
http://www.postgresql.org/message-id/ef524e81-b815-4122-a337-7e50bced5...@silentmedia.com
Basically a subselect with no offset is resulting in really poor
performance
Jeff Janes jeff.ja...@gmail.com writes:
I think the next step would be to run gdb -p pid (but don't start
gdb until backend is in the middle of a slow explain), then:
Sorry, I am lack debug symbols, so call trace is incomplete:
explain select i.item_id, u.user_id from items i left join users
Scott Marlowe scott.marl...@gmail.com writes:
I am running 8.4.15 and can try 8.4.17 if some patch has been applied
to it to address this issue. I just want to know should I
A: upgrade to 8.4.17
or
B: create a self contained test case.
A quick look at the release notes shows no planner
I also find this trace for other query:
explain select * from xview.user_items_v v where ( v.item_id = 132358330 );
#0 0x7ff766967620 in read () from /lib/libc.so.6
#1 0x7ff7689cfc25 in FileRead ()
#2 0x7ff7689ea2f6 in mdread ()
#3 0x7ff7689cc473 in ?? ()
#4
On Thu, Aug 1, 2013 at 5:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Scott Marlowe scott.marl...@gmail.com writes:
I am running 8.4.15 and can try 8.4.17 if some patch has been applied
to it to address this issue. I just want to know should I
A: upgrade to 8.4.17
or
B: create a self contained
Sergey Burladyan escribió:
I also find this trace for other query:
explain select * from xview.user_items_v v where ( v.item_id = 132358330 );
#0 0x7ff766967620 in read () from /lib/libc.so.6
#1 0x7ff7689cfc25 in FileRead ()
#2 0x7ff7689ea2f6 in mdread ()
#3
19 matches
Mail list logo
