Re: Huge overestimation in rows expected results in bad plan
От | bricklen |
---|---|
Тема | Re: Huge overestimation in rows expected results in bad plan |
Дата | |
Msg-id | AANLkTimxv5HeSSuL5_+6bUDvicE39wNheToT2Ow3mC1x@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Huge overestimation in rows expected results in bad plan (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Huge overestimation in rows expected results in bad plan
|
Список | pgsql-performance |
On Tue, Nov 9, 2010 at 3:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > bricklen <bricklen@gmail.com> writes: >> I have a query that is getting a pretty bad plan due to a massively >> incorrect count of expected rows. > > The query doesn't seem to match the plan. Where is that OR (c.id = > 38441828354::bigint) condition coming from? > > regards, tom lane > Ah sorry, I was testing it with and without that part. Here is the corrected query, with that as part of the join condition: explain analyze select c.id, c.transactionid, c.clickgenerated, c.confirmed, c.rejected, cr.rejectedreason from conversion c inner join conversionrejected cr on cr.idconversion = c.id or c.id = 38441828354 where date = '2010-11-06' and idaction = 12906 and idaffiliate = 198338 order by transactionid;
В списке pgsql-performance по дате отправления: