Il 10/06/2013 04:19, Jeff Janes ha scritto:
On further thought, that is not strange at all. You have two very
selective join conditions, and the planner assumes they are independent, so
that it can multiply the selectivities. But in reality they are completely
(or almost completely) dependent.
On Saturday, June 8, 2013, Jeff Janes wrote:
> On Sat, Jun 8, 2013 at 8:06 AM, Enrico Pirozzi
>
> > wrote:
>
>> Hi all,
>>
>> I have 2 tables:
>>
>> table1 (field1,field2,.)
>> table2 (field1,field2,field3,.)
>>
>> field1 is an uuid type
>>
>
> Is it a primary key? Is there a foreign ke
On Sat, Jun 8, 2013 at 8:06 AM, Enrico Pirozzi wrote:
> Hi all,
>
> I have 2 tables:
>
> table1 (field1,field2,.)
> table2 (field1,field2,field3,.)
>
> field1 is an uuid type
>
Is it a primary key? Is there a foreign key constraint between them?
> field2 is a timestamp with time zone
Hi all,
I have 2 tables:
table1 (field1,field2,.)
table2 (field1,field2,field3,.)
field1 is an uuid type
field2 is a timestamp with time zone type.
If I execute:
explain (analyze on, timing off)
select B.field3,A.field1,A.field2
FROM table1 A INNER JOIN table2 B
using (field1,field2)
On Thu, Oct 21, 2010 at 8:51 PM, DM wrote:
> Why is the difference in query plan, and the total runtime. Both tables have
> the same btree index
>
>
> test=# explain analyze select * from test_seqindex1 where sid='AA023';
> QUERY
> PLAN
*Why is the difference in query plan, and the total runtime. Both tables
have the same btree index*
test=# explain analyze select * from test_seqindex1 where sid='AA023';
QUERY
PLAN
-
perfecto, thank you for the explanation.
- Deepak
On Thu, Oct 21, 2010 at 3:20 AM, Mathieu De Zutter wrote:
> On Thu, Oct 21, 2010 at 3:47 AM, DM wrote:
> > I was hoping the optimizer would do a join using index scan.
> >
> > Could some one please explain me why its not doing an index scan rath
On Thu, Oct 21, 2010 at 3:47 AM, DM wrote:
> I was hoping the optimizer would do a join using index scan.
>
> Could some one please explain me why its not doing an index scan rather than
> sequential scan .
A index scan would be probably slower here because you're asking for a
lot of rows. A lot
Question on Index scan:
--->
test=# \d test_seqindex1
Table "public.test_seqindex1"
Column | Type | Modifiers
+---+---
sid| character varying(13) | not null
nam
