Re: BUG #5358: Throwing unexpected ERROR
От | Gurjeet Singh |
---|---|
Тема | Re: BUG #5358: Throwing unexpected ERROR |
Дата | |
Msg-id | 65937bea1003030548p68a04812p96da41406ce2c363@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #5358: Throwing unexpected ERROR (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: BUG #5358: Throwing unexpected ERROR
|
Список | pgsql-bugs |
On Wed, Mar 3, 2010 at 8:37 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Mar 3, 2010 at 7:29 AM, Gurjeet Singh <singh.gurjeet@gmail.com> > wrote: > > I just realized that it is the subquery pull-up that is leading to this > > problem, not predicate push-down. Sleeping over it does really help I > guess > > :) > > > > So instead of the LIMIT 1000, OFFSET 0 clause is the right choice for > > preventing subquery pull-up without affecting the results. > > > > I don't think the optimizer has the push-down capabiity; I may be wrong. > > Maybe I'm just dense, but I don't understand what you're complaining > about here. The SELECT DISTINCT already acts as an optimization > fence, so why would you need another one? And what problem would you > expect it to solve? > > I am complaining about the ERROR when I don't specify OFFSET or LIMIT. The query isn't relevant. It is there just to illustrate the fact that two supposedly equivalent forms of a query are not treated equivalent after all by Postgres. You don't put that OFFSET clause, you get an ERROR. You put in that OFFSET clause and you get proper results. I hope my complain is clearer now. Best regards, -- gurjeet.singh @ EnterpriseDB - The Enterprise Postgres Company http://www.enterprisedb.com singh.gurjeet@{ gmail | yahoo }.com Twitter/Skype: singh_gurjeet Mail sent from my BlackLaptop device
В списке pgsql-bugs по дате отправления: