Josh Berkus writes:
>> The explanation is in
>> http://archives.postgresql.org/message-id/20130910132133.GJ1024477%40alap2.anarazel.de
>>
>> The referenced commit introduced a planner feature. Funnily you seem to
>> have been the trigger for it's introduction ;)
> Oh, crap, the "off the end of t
On Fri, Nov 8, 2013 at 6:04 AM, Jan Walter wrote:
> Hi,
>
> I would like to know, how does the size of the IN list affect query
> planner.
> I have a query
>
> select distinct on (event_id, tag_id) et.id,
>e.id as event_id, t.id as tag_id, t.name,
>t.user_id, t.shared, t.color,
>
Jan Walter writes:
> I would like to know, how does the size of the IN list affect query planner.
AFAICT, the reason the second plan is slow is the large number of checks
of the IN list. The planner does account for the cost of that, but it's
drastically underestimating that cost relative to the
Hi,
I would like to know, how does the size of the IN list affect query planner.
I have a query
select distinct on (event_id, tag_id) et.id,
e.id as event_id, t.id as tag_id, t.name,
t.user_id, t.shared, t.color,
case
when ea.id <> e.id then true
else false
