El 28 de noviembre de 2008 14:42, Alvaro Herrera
<[EMAIL PROTECTED]>escribió:
> Roberto Guevara escribió:
>
> > Lo del limit 1 es para emular una consulta fetch unitaria, que con lo que
> > trae setea un buffer de registro actual de otra libreria. Si no, yo lo
> haria
> > con cursores nativos del
Roberto Guevara escribió:
> Lo del limit 1 es para emular una consulta fetch unitaria, que con lo que
> trae setea un buffer de registro actual de otra libreria. Si no, yo lo haria
> con cursores nativos del motor, pero para hacerlo tomara tiempo...
Si haces OFFSET/LIMIT incrementando ambos valor
2008/11/28 Alvaro Herrera <[EMAIL PROTECTED]>
> Roberto Guevara escribió:
>
> > El tema completo es el siguiente, yo uso una libreria que internamente
> > agarra cualquier consulta y la desarma en consultas individuales (en
> 'grosso
> > modo' con un LIMIT 1) que recorren ciclicamente la PK para t
Roberto Guevara escribió:
> El tema completo es el siguiente, yo uso una libreria que internamente
> agarra cualquier consulta y la desarma en consultas individuales (en 'grosso
> modo' con un LIMIT 1) que recorren ciclicamente la PK para traer los
> resultados fila por fila. El tema es que al cor
2008/11/28 Alvaro Herrera <[EMAIL PROTECTED]>
> Roberto Guevara escribió:
> > Como decis, al pegar el sql no me fije que pegue el del count , la
> consulta
> > que tira el error es con * y la salida la redirecciono a un archivo:
> >
> > -bash-3.00$ cat prueba.sql
> > \c danisant;
> > set search_pa
Roberto Guevara escribió:
> Como decis, al pegar el sql no me fije que pegue el del count , la consulta
> que tira el error es con * y la salida la redirecciono a un archivo:
>
> -bash-3.00$ cat prueba.sql
> \c danisant;
> set search_path=estadis;
> select * from datest where fcfec>='2006-12-01' a
Como decis, al pegar el sql no me fije que pegue el del count , la consulta
que tira el error es con * y la salida la redirecciono a un archivo:
-bash-3.00$ cat prueba.sql
\c danisant;
set search_path=estadis;
select * from datest where fcfec>='2006-12-01' and fcfec<='2008-12-31';
-bash-3.00$ psql
> -Mensaje original-
> De: Alvaro Herrera [mailto:[EMAIL PROTECTED]
>
> Fernando Hevia escribió:
>
> > Roberto,
> > Creo que el thread que pasó Emanuel da en el clavo. Allí
> Tom Lane tira
> > una pista por donde indagar.
> > Cito:
> > And, in fact, this is the typical behavior wh
El día 27 de noviembre de 2008 21:46, Alvaro Herrera
<[EMAIL PROTECTED]> escribió:
> Emanuel Calvo Franco escribió:
>> 2008/11/27 Alvaro Herrera <[EMAIL PROTECTED]>:
>
>> >> Traduciendo: dice que los errores que recibiste es el comportamiento en
>> >> viejas versiones del cliente cuando se queda si
Emanuel Calvo Franco escribió:
> 2008/11/27 Alvaro Herrera <[EMAIL PROTECTED]>:
> >> Traduciendo: dice que los errores que recibiste es el comportamiento en
> >> viejas versiones del cliente cuando se queda sin memoria. A ello sugiere
> >> usar un cursor para traer una cantidad limitada de filas p
2008/11/27 Alvaro Herrera <[EMAIL PROTECTED]>:
> Fernando Hevia escribió:
>
>> Roberto,
>> Creo que el thread que pasó Emanuel da en el clavo. Allí Tom Lane tira una
>> pista por donde indagar.
>> Cito:
>> And, in fact, this is the typical behavior when it runs out of memory
>> for the result s
Fernando Hevia escribió:
> Roberto,
> Creo que el thread que pasó Emanuel da en el clavo. Allí Tom Lane tira una
> pista por donde indagar.
> Cito:
> And, in fact, this is the typical behavior when it runs out of memory
> for the result set :-( ...
> Traduciendo: dice que los errores que rec
> Econtre este:
> http://archives.postgresql.org/pgsql-sql/2002-09/msg00343.php
>
Roberto,
Creo que el thread que pasó Emanuel da en el clavo. Allí Tom Lane tira una
pista por donde indagar.
Cito:
And, in fact, this is the typical behavior when it runs out of memory
for the result set :-( ...
set search_path=estadis;
select count(*) from datest where fcfec>='2006-12-01' and
fcfec<='2008-12-31';
2008/11/27 Alvaro Herrera <[EMAIL PROTECTED]>
> Roberto Guevara escribió:
>
> > y la consulta se tarda una barbaridad. Lo extraño son esos mensajes que
> > googleando un poco a casi nadie le
Roberto Guevara escribió:
> y la consulta se tarda una barbaridad. Lo extraño son esos mensajes que
> googleando un poco a casi nadie le salio. Hay algun tipo de error en la
> transmision?
Cuál es la consulta?
--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Las
El día 27 de noviembre de 2008 18:34, Alvaro Herrera
<[EMAIL PROTECTED]> escribió:
> Roberto Guevara escribió:
>> Hola a todos. Tengo un servidor dedicado a postgres bastante grande, pero
>> cuando hago una consulta desde un cliente psql 7.3 al motor 8.43 en medio
>> de la consulta me tira estos m
El motor es 8.3.5 y no hay nada entre los servers, probamos haciendo un scp
de un archivo de 500mb y lo transmitio creo que a 300Mbps, esta bien?
El 27 de noviembre de 2008 17:34, Alvaro Herrera
<[EMAIL PROTECTED]>escribió:
> Roberto Guevara escribió:
> > Hola a todos. Tengo un servidor dedicado
Roberto Guevara escribió:
> Hola a todos. Tengo un servidor dedicado a postgres bastante grande, pero
> cuando hago una consulta desde un cliente psql 7.3 al motor 8.43 en medio
> de la consulta me tira estos mensajes:
> ...
> server sent data ("D" message) without prior row description ("T" mess
18 matches
Mail list logo
