Hi again,
/*Hedayat Vatankhah*/ wrote on Sun, 31 Jan 2016 01:20:53 +0330:
Hi,
/*David Rowley*/ wrote on Sun, 31 Jan 2016 04:57:04 +1300:
On 31 January 2016 at 01:30, Hedayat Vatankhah
wrote:
Personally, I expect both queries below to perform exactly the same:
SELECT
t1.id, *
FROM
Hi,
/*David Rowley*/ wrote on Sun, 31 Jan 2016 04:57:04 +1300:
On 31 January 2016 at 01:30, Hedayat Vatankhah wrote:
Personally, I expect both queries below to perform exactly the same:
SELECT
t1.id, *
FROM
t1
INNER JOIN
t2 ON t1.id = t2.id
where t1.id > -92233720365134113
Well, as I can see it was just few phrases unless I miss something. May be
it's worth to bring it to -hackers for a wider discussion?
Best regards, Vitalii Tymchyshyn
Сб, 30 січ. 2016 12:31 David Rowley пише:
> On 31 January 2016 at 06:14, Vitalii Tymchyshyn wrote:
> > It may be more for -hack
On 31 January 2016 at 06:14, Vitalii Tymchyshyn wrote:
> It may be more for -hackers, but I often hear "this wont be used because of
> planning time increase". Now as I know we have statistics on real query time
> after few runs that is used to decide if plan should be switched.
> Can this statist
It may be more for -hackers, but I often hear "this wont be used because of
planning time increase". Now as I know we have statistics on real query
time after few runs that is used to decide if plan should be switched.
Can this statistics be used to apply advanced planning features for
relatively l
On 31 January 2016 at 01:30, Hedayat Vatankhah wrote:
> Personally, I expect both queries below to perform exactly the same:
>
> SELECT
> t1.id, *
> FROM
> t1
> INNER JOIN
> t2 ON t1.id = t2.id
> where t1.id > -9223372036513411363;
>
> And:
>
> SELECT
> t1.id, *
> FROM
> t1