2009/5/9 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Fri, May 8, 2009 at 5:40 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Sat, May 09, 2009 at 01:28:03PM -0400, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Fri, May 8, 2009 at 5:40 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Yeah, we went over this on the spanish list, turned out that I
couldn't remember about syncscan :-)
I
On Sun, May 10, 2009 at 2:03 AM, David Fetter da...@fetter.org wrote:
On Sat, May 09, 2009 at 01:28:03PM -0400, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Fri, May 8, 2009 at 5:40 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Yeah, we went over this on the spanish
2009/5/8 David Fetter da...@fetter.org:
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
On Fri, May 8, 2009 at 5:40 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
Merlin Moncure mmonc...@gmail.com writes:
On Fri, May 8, 2009 at 5:40 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
Hi all.
I'll make this faster.
I hace this table and this function:
CREATE FUNCTION pg_round_random_range(integer, integer) RETURNS integer
LANGUAGE plperl IMMUTABLE STRICT
AS $_X$
my($imin, $imax) = @_;
if ($_[0] == $_[1]){
return $_[0];}
if($imin $imax){
$imin = $_[1];
$imax =
Emanuel Calvo Franco postgres@gmail.com 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,
2009/5/8 Tom Lane t...@sss.pgh.pa.us:
Emanuel Calvo Franco postgres@gmail.com 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
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 the
2009/5/8 David Fetter da...@fetter.org:
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
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 ORDER BY
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 query' i see that (as
expected) the seq scan
is occurring.
That's correct? Is logical that if the scan is sequential in the
On Fri, May 08, 2009 at 06:40:33PM -0300, Emanuel Calvo Franco wrote:
2009/5/8 David Fetter da...@fetter.org:
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
14 matches
Mail list logo
