Sergey Burladyan writes:
> Hot standby:
...
> ' -> Index Only Scan using items_user_id_idx on public.items
> (cost=0.00..24165743.48 rows=200673143 width=8) (actual
> time=56064.499..56064.499 rows=1 loops=1)'
> 'Output: public.items.
Jeff Janes writes:
> On Fri, Aug 2, 2013 at 2:58 AM, Sergey Burladyan wrote:
> >
> > PS: I think my main problem is here:
> > select min(user_id) from items;
> > min
> > -
> >1
> > (1 row)
> >
> > Time: 504.520 ms
>
> T
Tom Lane writes:
> Jeff Janes writes:
> > On Thu, Aug 1, 2013 at 5:16 PM, Sergey Burladyan
> > wrote:
> >> If I not mistaken, may be two code paths like this here:
> >> (1) mergejoinscansel -> scalarineqsel-> ineq_histogram_selectivity ->
>
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 0x7ff7689ccf54
Jeff Janes writes:
> I think the next step would be to run gdb -p (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 u on u.user_id
= i.us
Jeff Janes 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 open
7356 write
21
Sergey Burladyan 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
> --
>
nable_mergejoin to off does not help with this query.
--
Sergey Burladyan
On Thu, Aug 1, 2013 at 2:04 PM, Thomas Reiss wrote:
> 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 s
01.08.2013 14:05 пользователь "Thomas Reiss"
написал:
>
> 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.
can using items_item_ux on items i (cost=0.00..358.84 rows=1
width=16)
Index Cond: (item_id = 169946840)
-> Index Only Scan using users_user_id_pkey on users u
(cost=0.00..38.30 rows=1 width=8)
Index Cond: (user_id = i.user_id)
time: 28.874 ms
--
Sergey Burladyan
.12.50 rows=1 width=4) (actual
time=0.000..0.000 rows=0 loops=1)
One-Time Filter: false
-> Function Scan on generate_series n (cost=0.00..12.50 rows=1
width=4) (never executed)
Total runtime: 0.053 ms
(9 rows)
Is it right ?
--
Sergey Burladyan
--
Sent via p
pg_size_pretty(pg_total_relation_size('a')) as total,
pg_size_pretty(pg_relation_size('a')) as table;
total | table
-+-
9792 kB | 5096 kB
203068.314 ms VS 2405.481 ms, is this behaviour normal ?
Thanks !
--
Sergey Burladyan
--
Sent via pgsql-performance
13 matches
Mail list logo
