On Fri, Oct 12, 2012 at 3:33 AM, Alban Hertroys wrote:
> On 12 October 2012 04:55, urkpostenardr wrote:
>> Hi,
>>
>> Is this bug in Postgres ?
>> If yes, is it fixed in latest release ?
>> Second query should return 2 rows instead of 1 ?
>>
>> create table t(i int);
>> insert into t values(1);
>>
On 12 October 2012 04:55, urkpostenardr wrote:
> Hi,
>
> Is this bug in Postgres ?
> If yes, is it fixed in latest release ?
> Second query should return 2 rows instead of 1 ?
>
> create table t(i int);
> insert into t values(1);
> insert into t values(2);
> insert into t values(3);
> pgdb=# selec
urkpostenardr wrote:
> Is this bug in Postgres ?
> If yes, is it fixed in latest release ?
> Second query should return 2 rows instead of 1 ?
>
> create table t(i int);
> insert into t values(1);
> insert into t values(2);
> insert into t values(3);
> pgdb=# select i from t order by i limit 922337
2009/5/9 Tom Lane :
> Merlin Moncure writes:
>> On Fri, May 8, 2009 at 5:40 PM, Alvaro Herrera
>> wrote:
>>> Yeah, we went over this on the spanish list, turned out that I couldn't
>>> remember about syncscan :-)
>
>> I like the new behavior. It really encourages proper use of order by,
>> becau
On Sun, May 10, 2009 at 2:03 AM, David Fetter wrote:
> On Sat, May 09, 2009 at 01:28:03PM -0400, Tom Lane wrote:
>> Merlin Moncure writes:
>> > On Fri, May 8, 2009 at 5:40 PM, Alvaro Herrera
>> > wrote:
>> >> Yeah, we went over this on the spanish list, turned out that I
>> >> couldn't remember
On Sat, May 09, 2009 at 01:28:03PM -0400, Tom Lane wrote:
> Merlin Moncure writes:
> > On Fri, May 8, 2009 at 5:40 PM, Alvaro Herrera
> > wrote:
> >> Yeah, we went over this on the spanish list, turned out that I
> >> couldn't remember about syncscan :-)
>
> > I like the new behavior. It really
Merlin Moncure writes:
> On Fri, May 8, 2009 at 5:40 PM, Alvaro Herrera
> wrote:
>> Yeah, we went over this on the spanish list, turned out that I couldn't
>> remember about syncscan :-)
> I like the new behavior. It really encourages proper use of order by,
> because the natural ordering resul
On Fri, May 8, 2009 at 5:40 PM, Alvaro Herrera
wrote:
> David Fetter escribió:
>> On Fri, May 08, 2009 at 06:10:18PM -0300, Emanuel Calvo Franco wrote:
>> > Hi all.
>> >
>> > I'll make this faster.
>> >
>> > I hace this table and this function:
>>
>> You should only ever assume that your SELECT's
2009/5/8 David Fetter :
> On Fri, May 08, 2009 at 06:40:33PM -0300, Emanuel Calvo Franco wrote:
>>
>> I test it in the first time :)
>>
>> With the 'order by' it works well, but in 'theory'
>
> The theory under which you should operate is that the underlying
> implementation only gives you the orde
On Fri, May 08, 2009 at 06:40:33PM -0300, Emanuel Calvo Franco wrote:
> 2009/5/8 David Fetter :
> > On Fri, May 08, 2009 at 06:10:18PM -0300, Emanuel Calvo Franco wrote:
> >> Hi all.
> >>
> >> I'll make this faster.
> >>
> >> I hace this table and this function:
> >
> > You should only ever assume
Emanuel Calvo Franco wrote:
>
> Executing 'select * from datos limit 1 offset 15' two times i
have different
> result sets.
> When i execute 'explain analyze verbose ' i see that (as
> expected) the seq scan
> is occurring.
>
>
> That's correct? Is logical that if the scan is sequential in
David Fetter escribió:
> On Fri, May 08, 2009 at 06:10:18PM -0300, Emanuel Calvo Franco wrote:
> > Hi all.
> >
> > I'll make this faster.
> >
> > I hace this table and this function:
>
> You should only ever assume that your SELECT's output will have a
> particular ordering when you include an O
2009/5/8 David Fetter :
> On Fri, May 08, 2009 at 06:10:18PM -0300, Emanuel Calvo Franco wrote:
>> Hi all.
>>
>> I'll make this faster.
>>
>> I hace this table and this function:
>
> You should only ever assume that your SELECT's output will have a
> particular ordering when you include an ORDER BY
On Fri, May 08, 2009 at 06:10:18PM -0300, Emanuel Calvo Franco wrote:
> Hi all.
>
> I'll make this faster.
>
> I hace this table and this function:
You should only ever assume that your SELECT's output will have a
particular ordering when you include an ORDER BY clause that actually
specifies th
2009/5/8 Tom Lane :
> Emanuel Calvo Franco writes:
>> Executing 'select * from datos limit 1 offset 15' two times i have
>> different
>> result sets.
>
> The "synchronous scan" logic is probably responsible. Turn off
> synchronize_seqscans if this behavior bothers you.
>
>
Emanuel Calvo Franco writes:
> Executing 'select * from datos limit 1 offset 15' two times i have
> different
> result sets.
The "synchronous scan" logic is probably responsible. Turn off
synchronize_seqscans if this behavior bothers you.
regards, tom lane
--
Sent
am 17.01.2006, um 16:43:36 +0100 mailte MG folgendes:
> Hello,
>
> I want to show an overview where you can place 16 data sets.
> I use the sql-statement
> SELECT F1,F2 FROM testtable limit 16 offset 0
>
> To show different pages I vary the value for offset.
>
> But if I want to stay on a speci
17 matches
Mail list logo
