Pgpool te servira señor , en este sitio te describe claramente como hacer un
Clusted de Alta disponibilidad,
http://linuxsilo.net/articles/postgresql-pgpool.html yo en Diciembre lo hice
y me funko perfectamente, igual tube mis incovenientes en la hora de
entender como realizar, pero sirve.
Cualqu
saludos
yo uso pgpool, si puedes lee un poco mas para ver si es lo que buscas
http://linuxsilo.net/articles/postgresql-pgpool.html
El 21 de febrero de 2011 14:34, Lazaro Ruben Garcia Martinez <
lgarc...@estudiantes.uci.cu> escribió:
> Hola a todos. Les escribo porque tengo unas dudas relacio
Hola a todos. Les escribo porque tengo unas dudas relacionadas con Slony-I. En
la documentación publicada en el sitio oficial, de la versión 1.2 mencionan que
no permite hacer failover automático y que además funciona para un número
limitado de servidores (12) un número mayor a esta cantidad pue
Como bien dice Jaime, el problema proviene de un error en el enconding usado
en el respaldo de la base de datos original y de la nueva base de datos
donde se está restaurando. Para arreglar el problema de claves duplicadas es
necesario restaurar en una base de datos recién creada (sin intentos
prev
Tenés razón. Utilizando timing la query me tarda unos 259,402 ms, y
te muestra todos los datos al instante. Voy a probar lo de "unaligned".
El tiempo igualmente midiéndolo desde un cliente con PHP con funciones
para medir el tiempo me tarda unos 5 o 6 segundos en procesar el apache
a pesar de q
mm, el problema tal vez esta entonces en el trigger.
tal vez la consulta que se hace internamente no esta optimizada, o por el
hecho de hacer transacciones esta se hace lenta.
Tienes esa tabla donde consultas con indices ???, es una tabla diferente o
es sobre la misma??
El 21 de febrero de 2011 11
Hola de nuevo.
Bueno, la tabla recibe una serie de coordenadas UTM y lo que hace la tabla
al detectar el insert es llamar al trigger para conseguir un valor en la
columna the_geom, esto lo hace bien en los primeros registros, pero cuando
se insertan nuevos registros cada cierto tiempo pues pierde
Al usar:
COPY backtesting.eurusd (DateTimeStr,AskPrice,BidPrice)
FROM E'C:\\F241BB5A124D648A71B6CE4227EB93CC.csv'
WITH DELIMITER ','
Tanto terminando con punto y coma como sin el, recibo el mensaje de error
sigiente:
ERROR: no existe la relación «backtest
Lo mejor para darnos cuenta que pasa, es ver la estructura de la tabla
destino. Aqui pueden existir muchos factiores:
1. Vacuum
2. Indices
3. Contsraint
4. Triggers sobre la tabla final.
5.
Que tantos datos quieres subir?
El 21 de febrero de 2011 10:37, Miguel Angel Hernandez Moreno <
miguel
El día 21 de febrero de 2011 12:37, Miguel Angel Hernandez Moreno
escribió:
> saludos
>
> trata de darle mantenimiento, un vacuum, posiblemente como comentaban si tu
> tabla esta
> muy saturada y un mantenimiento podria ayudarte a darle un poco de velocidad
Fijate que no tenga triggers también ..
saludos
trata de darle mantenimiento, un vacuum, posiblemente como comentaban si tu
tabla esta
muy saturada y un mantenimiento podria ayudarte a darle un poco de velocidad
El 21 de febrero de 2011 08:24, Francisco Rodríguez escribió:
> Bueno, el postgres lo tengo configurado de fábrica, por lo
Y precisamente que es un esquema .xsd y mas aun que es un bean porque no creo
que sea de habichuela.
*---*
*-Edwin Quijada
*-Developer DataBase
*-JQ Microsistemas
*-Soporte PostgreSQL
*-www.jqmicrosistemas.com
*-809-849-8087
*
Prueba con esto
COPY backtesting.eurusd (DateTimeStr,AskPrice,BidPrice) FROM
E'C:\\F241BB5A124D648A71B6CE4227EB93CC.csv' WITH DELIMITER ',';
--- On Mon, 2/21/11, Francisco Gonzalez Velasco wrote:
From: Francisco Gonzalez Velasco
Subject: Re: [pgsql-es-ayuda] Denied post to pgsql-es-ayuda
To:
>
> Buenos días:
>
> Soy un nuevo usuario de PostgreSQL 9.0 y quiero importar un archivo CSV a
> una tabla PostgreSQL.
>
> He definido una base de datos (Schema) con nombre backtesting y en ella una
> tabla (table) llamada eurusd con 3 columnas.
>
>
> Con el editor SQL he introducido la siguiente
Bueno, el postgres lo tengo configurado de fábrica, por lo que no se si será
eso, aunque en la tabla de destino tengo dos primary keys, voy a intentar
hacerlo sin estas.
Un saludo y gracias.
Francisco Rodríguez Torres
El 21/02/2011, a las 15:06, Manuel Fernando Aller
escribió:
>
> El 21
El 21 de febrero de 2011 11:01, Francisco Rodríguez escribió:
> Hola estoy usando dbsync para pasar datos desde mysql a postgresql. El caso
> que cuando hago el insert de unos 12000 registros va muy lento, ya que
> cuando hago select mientras esta insertando lo hace a razón de 5 registros
> cada
Hola estoy usando dbsync para pasar datos desde mysql a postgresql. El caso que
cuando hago el insert de unos 12000 registros va muy lento, ya que cuando hago
select mientras esta insertando lo hace a razón de 5 registros cada 10 segundos
más o menos, ¿a que puede ser debido?
Un saludo.
Excerpts from angel Iracheta's message of lun feb 21 10:54:43 -0300 2011:
> > ¿De qué tipo es la columna fecha_foto?
>
> La columna es de tipo "Date".
Hmm, qué extraño. Creo que la única forma de saber exactamente en qué
se está gastando tiempo es hacer un poco de "profiling". Ignoro qué
herram
> ¿De qué tipo es la columna fecha_foto?
La columna es de tipo "Date".
En la tabla tengo una columna "Id" del tipo serial, para tener una
referencia única para cada registro, y si hacemos la prueba:
select * from foto_inventario where id=915647;
De primera intención:
En la combinación postgres
Excerpts from Ezequiel Lovelle's message of dom feb 20 18:20:45 -0300 2011:
> La cuestión es que conservando la conflagración por defecto e
> instalación, testeando Postgres con el software pgbench (pgbench -i -h
> host -p port -U user -d bbdd)
>
> que crea unos 100.000 registros en una
> tabla l
Excerpts from angel Iracheta's message of lun feb 21 02:14:43 -0300 2011:
> Digamos para la fecha 15/11/2010 (15-Nov-2010):
>
> select * from foto_inventario where fecha_foto='2010-11-15';
>
> En la combinación postgresql-debian: 4.935 ms
> En la combinación postgresql-freebsd: 11.126 ms
¿De qu
21 matches
Mail list logo
