.com/blog/pgbouncer-scram-authentication-postgresql
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
";
Con eso el sistema continuaría instalando todas las actualizaciones,
excepto lo de postgresql que habría que instalarlo a mano, lo cual da
control sobre el momento de reiniciar el servicio.
Saludos
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)
s
no esté listo el upgrade, tratar de hacer optimizaciones es pérdida de
tiempo.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
"E pur si muove" (Galileo Galilei)
Romero, Fernando escribió:
> postgres@pgda:/etc/postgresql/13/main$ psql
> psql (13.16 (Debian 13.16-0+deb11u1))
> Digite «help» para obtener ayuda.
Pues aquí el psql te funcionó perfectamente. Y nunca mostraste el psql
que fallaba.
--
Álvaro Herrera 48°01'N 7°
Romero, Fernando escribió:
> Es el único pg_hba.conf que tiene el servidor
Entonces estás mirando el servidor equivocado.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
usuario «xxx»
>
> Cual es el error aca si en el pg_hba.conf para las pruebas le puse a todos
> "trust"?
Seguramente estás editando un archivo que no es el que el servidor está
leyendo.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
"
s subconsultas, que
esencialmente significa que las elimina y lo vuelve a la misma
estructura que si no tuvieras la subconsulta, por eso no ves ninguna
mejora. Pero si a la subconsulta le agregas OFFSET 0, entonces se
convierte en una "barrera de optimización", evitando que haga ese
etiendo el scan de esa tabla en un subselect. Cuando nos
cuentes del resultado de arriba puedo explicar cómo se hace esto.
Saludos
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Sallah, I said NO camels! That's FIVE camels; can't you count?"
(Indiana Jones)
(most_common_freqs)
from pg_stats
where tablename = 'companies';
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
ve la query
> en menos de un segundo , lo tengo resuelto así pero me quedo con la duda de
> porque el planificador lo hace mal de la otra manera (para mi)
Hmm, es raro. ¿Has visto el tamaño de los índices? ¿Qué tienes en
effective_cache_size y shared_buffers?
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
10 matches
Mail list logo
