Robert Haas writes:
> On Wed, Jun 1, 2016 at 7:29 AM, Pavel Stehule wrote:
>> When I tested some queries, I found strange plan
>> postgres=# explain analyze select s.nazev, o.nazev, o.pocet_obyvatel from
>> (select nazev, array(select id from obce_pocet_obyvatel where okresy.id =
>> okres_id orde
On Thu, Jul 7, 2016 at 4:13 PM, Pavel Stehule wrote:
> 2016-07-07 21:57 GMT+02:00 Robert Haas :
>> On Wed, Jun 1, 2016 at 7:29 AM, Pavel Stehule
>> wrote:
>> > Hi
>> >
>> > When I tested some queries, I found strange plan
>> >
>> > postgres=# explain analyze select s.nazev, o.nazev, o.pocet_obyva
2016-07-07 21:57 GMT+02:00 Robert Haas :
> On Wed, Jun 1, 2016 at 7:29 AM, Pavel Stehule
> wrote:
> > Hi
> >
> > When I tested some queries, I found strange plan
> >
> > postgres=# explain analyze select s.nazev, o.nazev, o.pocet_obyvatel from
> > (select nazev, array(select id from obce_pocet_ob
On Wed, Jun 1, 2016 at 7:29 AM, Pavel Stehule wrote:
> Hi
>
> When I tested some queries, I found strange plan
>
> postgres=# explain analyze select s.nazev, o.nazev, o.pocet_obyvatel from
> (select nazev, array(select id from obce_pocet_obyvatel where okresy.id =
> okres_id order by pocet_obyvate
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> tour=# explain analyze select * from tours where
>> ( operator_id in (2,3,4,5,7) and type_id = 4 ) or
>> ( operator_id = 8 and type_id = 3);
> Actually this plan looks very strange to me. One would expect it to only use
> type_idx twic
> EXPLAIN
> tour=# explain analyze select * from tours where
>( operator_id in (2,3,4,5,7) and type_id = 4 ) or
>( operator_id = 8 and type_id = 3);
> NOTICE: QUERY PLAN:
>
> Index Scan using type_idx, type_idx, type_idx, type_idx, type_idx, type_idx on tours
> (cost=
Tom,
one more question.
What's the difference for planner between 2 queries ?
For the first query I have plain index scan, but multiple
index scan for second.
tour=# explain analyze select * from tours where
( operator_id in (2,3,4,5,7) and type_id = 2 );
NOTICE: QUERY PLAN:
I
Thanks Tom,
On Mon, 13 May 2002, Tom Lane wrote:
> Oleg Bartunov <[EMAIL PROTECTED]> writes:
> > tour=# explain analyze select * from tours where
> > ( operator_id in (2,3,4,5,7) and type_id = 2 ) or
> > ( operator_id = 8 and type_id=4 );
>
> > Index Scan using type
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> What's the difference for planner between 2 queries ?
> tour=# explain analyze select * from tours where
> ( operator_id in (2,3,4,5,7) and type_id = 2 );
> tour=# explain analyze select * from tours where
>( operator_id i
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Is this what the TODO entry 'Make IN / NOT IN have similar performance
> as EXISTS' means?
No. The TODO item is talking about IN with a sub-SELECT, which is not
optimized at all at the moment. IN with a list of scalar values is
converted to ((x = value
It appears it scanes the type_idx once per opereator. IN gets broken
down into ORs
Is this what the TODO entry 'Make IN / NOT IN have similar performance
as EXISTS' means?
--
Rod
- Original Message -
From: "Oleg Bartunov" <[EMAIL PROTECTED]>
To: "Pgsql Hackers" <[EMAIL PROTECTED]>; "Tom
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> tour=# explain analyze select * from tours where
> ( operator_id in (2,3,4,5,7) and type_id = 2 ) or
> ( operator_id = 8 and type_id=4 );
> Index Scan using type_idx, type_idx, type_idx, type_idx, type_idx, type_idx on tours
12 matches
Mail list logo
