- Mensagem original -
> De: "Atul Kumar"
> Para: "pgsql-general"
> Enviadas: Sexta-feira, 7 de maio de 2021 3:34:44
> Assunto: idle_in_transaction_session_timeout
> Hi,
> I have postgres 9.5 version running on my machine.
> When I am trying to find out the parameter
> idle_in_transac
- Mensagem original -
> De: "Magnus Hagander"
> Para: "Laurenz Albe"
> Cc: "Alvaro Herrera" , "luis.roberto"
> , "pgsql-general"
>
> Enviadas: Terça-feira, 27 de abril de 2021 4:05:42
> Assunto: Re: DB size
> Yeah, you want to use pg_relation_filenode(oid) rather than looking
> directl
- Mensagem original -
> De: "Alvaro Herrera"
> Para: "luis.roberto"
> Cc: "pgsql-general"
> Enviadas: Segunda-feira, 26 de abril de 2021 17:45:34
> Assunto: Re: DB size
> I would guess that there are leftover files because of those crashes you
> mentioned. You can probably look for fi
- Mensagem original -
> De: "Josef Šimánek"
> Para: "luis.roberto"
> Cc: "pgsql-general"
> Enviadas: Segunda-feira, 26 de abril de 2021 17:40:05
> Assunto: Re: DB size
> Do you have any indexes in mydb database?
Yes, I do. I believe pg_total_relation_size accounts for these. These
Hi!
I've looked around, but could only find very old answers to this question, and
maybe it changed since then...
I'm struggling to identify the cause of the difference in size between the sum
of all relations (via pg_total_relation_size) and pg_database_size:
SELECT sum(pg_total_relation_s
- Mensagem original -
> Any idea how to approach it?
Hi!
https://www.postgresql.org/docs/current/sql-savepoint.html
Luis R. Weck
> De: "sivapostgres"
> Para: "Benedict Holland"
> Cc: "pgsql-general" , "Thomas Kellerer"
>
> Enviadas: Quarta-feira, 17 de fevereiro de 2021 11:09:38
> Assunto: Re: Slow while inserting and retrieval (compared to SQL Server)
> So far no performance tuning done for sql server. It works fine f
- Mensagem original -
> De: "sivapostgres"
> Para: "luis.roberto"
> Cc: "pgsql-general"
> Enviadas: Quarta-feira, 17 de fevereiro de 2021 9:54:18
> Assunto: Re: Slow while inserting and retrieval (compared to SQL Server)
> Hello,
> Yes, that's what I feel. With no records in any table
- Mensagem original -
> De: sivapostg...@yahoo.com
> Para: "pgsql-general"
> Enviadas: Quarta-feira, 17 de fevereiro de 2021 9:01:15
> Assunto: Re: Slow while inserting and retrieval (compared to SQL Server)
>
> Hello,
>
> Using Postgres 11 in Windows Server 2012 & Powerbuilder
> Worki
> De: "Luca Ferrari"
> Para: "pgsql-general"
> Enviadas: Sexta-feira, 12 de fevereiro de 2021 8:00:46
> Assunto: pg_stat_progress_vacuum empty when running vacuum full
> Hi all,
> I'm running 11.5 and I'm monitoring pg_stat_progress_vacuum every 2
> seconds, while doing from another connection
De: "Thorsten Schöning"
Para: "pgsql-general"
Enviadas: Terça-feira, 9 de fevereiro de 2021 12:52:02
Assunto: How does Postgres decide if to use additional workers?
So, based on which facts does Postgres decide if to use aadditional
workers or not? Can I see those decisions explained somewhe
Hi!
Analyzing a table which has a statistic object raises the message: statistics
object "public.new_statistic" could not be computed for relation
"public.client"
De: "Charles Clavadetscher"
Para: "luis.roberto"
Cc: "pgsql-general"
Enviadas: Quarta-feira, 30 de setembro de 2020 10:46:39
Assunto: Re: Table sizes
Hello
On 2020-09-30 14:11, luis.robe...@siscobra.com.br wrote:
> Hi!
>
> I'm trying to use this query to get table sizes, however I'
Hi!
I'm trying to use this query to get table sizes, however I'm getting a strange
error:
select tablename,pg_relation_size(tablename::text)
from pg_tables;
In PG 13:
SQL Error [42P01]: ERROR: relation "sql_implementation_info" does not exist
In PG 12:
SQL Error [42P01]: ERROR: relati
De: "Ron"
Para: "pgsql-general"
Enviadas: Segunda-feira, 14 de setembro de 2020 13:10:23
Assunto: Re: Effective IO Concurrency
On 9/14/20 11:03 AM, Laurenz Albe wrote:
> On Mon, 2020-09-14 at 10:39 -0300, luis.robe...@siscobra.com.br wrote:
>> In PostgreSQL 13, the way of using effective_i
Hi!
In PostgreSQL 13, the way of using effective_io_concurrency has changed. Until
v12, I used 200 for this value (using SSD drives). Using the new formula
described in [ https://www.postgresql.org/docs/13/release-13.html |
https://www.postgresql.org/docs/13/release-13.html ] gives me 1176. Ho
Hi,
If "n" is indexed, it should run quickly. Can you share the execution plan for
your query?
De: "Klaudie Willis"
Para: "pgsql-general"
Enviadas: Sexta-feira, 28 de agosto de 2020 8:29:58
Assunto: Performance of "distinct with limit"
Hi,
Ran into this under-optimized query executi
- Mensagem original -
De: "David Rowley"
Para: "luis.roberto"
Cc: "Fabrízio de Royes Mello" , "pgsql-general"
Enviadas: Domingo, 12 de julho de 2020 5:29:08
Assunto: Re: Join optimization
On Sun, 12 Jul 2020 at 06:59, wrote:
>
> I'm sorry for the bad example.
>
> Here is another, wi
I'm sorry for the bad example.
Here is another, with some data on PG: [
https://dbfiddle.uk/?rdbms=postgres_13&fiddle=ccfd1c4fa291e74a6db9db1772e2b5ac
|
https://dbfiddle.uk/?rdbms=postgres_13&fiddle=ccfd1c4fa291e74a6db9db1772e2b5ac
] and Oracle: [
https://dbfiddle.uk/?rdbms=oracle_18&fiddle=
Hi!
Recently on a blogpost [1] I saw that Oracle was able to "optimize" a join
strategy by completely eliminating access to a table.
Heres the execution on Oracle 18c [2] and PostgreSQL 13 (beta) [3].
Is there a fundamental reason why PG can't do the same?
Thanks!
[1] [
https://blog.dbi-
Thanks Adrian,
> You could break it down into multiple transactions if there is way to specify
> ranges of records.
Say I couldn't break it up, would it be faster in or out of the transaction?
It depends whether you have concurrent transactions using the table. If you do,
I think it would be
21 matches
Mail list logo
