From: | Jaime Casanova <systemguards(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: avoid pulling up subquerys that contain volatile functions? |
Date: | 2005-10-11 20:34:15 |
Message-ID: | c2d9e70e0510111334p5b969dbdt5ba6072dc3546c15@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/9/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jaime Casanova <systemguards(at)gmail(dot)com> writes:
> > On 10/8/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> This is exactly the same example discussed in previous threads on this
> >> issue. Do you think it will change anyone's mind?
>
> > in any case, i still think that is better to get bad performance
> > because i forgot to correctly mark a function that to get incorrect
> > data from a correct query because a "gotcha"... there is a precedent
> > for this in postgres???
>
> Just to be clear, I'm in favor of changing it; but the majority opinion
> in the previous discussion seemed to be against.
>
>[snipped some interesting explanation about this]
>
> regards, tom lane
>
Maybe, document it? even with an example? and the workaround of course
--
regards,
Jaime Casanova
(DBA: DataBase Aniquilator ;)
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2005-10-11 21:37:23 | Re: slower merge join on sorted data chosen over |
Previous Message | Tom Lane | 2005-10-11 19:58:56 | Re: Spinlocks and CPU Architectures |