Need suggestions about live migration from PG 9.2 to PG 13

2021-07-06 Thread Lucas
Hello all, I'm currently working on a migration from PG 9.2 to PG 13 (RDS) and would like some suggestions, please. Our current database stack is: > master (pg 9.2) --> slave (pg 9.2) --> slave (pg 9.2 - cascading replication) >                          --> bucardo (ec2 instance) --> RDS (pg

Re: When to REINDEX a serial key?

2021-07-06 Thread Rob Sargent
> > There is no such thing as a lopsided B-tree, because a B-tree is by > definition self-balancing. Perhaps that answers your original question. > You do incur the cost of rebalancing often and the cost/frequency/extent is related to fill factor. > >

Re: Question about how to handle numeric (decimal) data types while using libpq

2021-07-06 Thread Peter Eisentraut
On 06.07.21 13:04, Sudheer H R wrote: I am trying to use libpq for interfacing with PostgreSQL from a C/C++ based application. I have tried to use binary format of data for both sending and receiving data to and from server (resultFormat = 1). As I understand most binary types, int, float

Re: When to REINDEX a serial key?

2021-07-06 Thread Peter Eisentraut
On 06.07.21 14:19, Ron wrote: On 7/6/21 4:52 AM, David Rowley wrote: On Tue, 6 Jul 2021 at 21:35, Ron wrote: The legacy RDBMS which I used to manage has a tool for analyzing (not in the Postgresql meaning of the word) an index, and displaying a histogram of how many layers deep various

Re: When to REINDEX a serial key?

2021-07-06 Thread Ron
On 7/6/21 4:52 AM, David Rowley wrote: On Tue, 6 Jul 2021 at 21:35, Ron wrote: The legacy RDBMS which I used to manage has a tool for analyzing (not in the Postgresql meaning of the word) an index, and displaying a histogram of how many layers deep various parts of an index are. Using that

Re: Question about how to handle numeric (decimal) data types while using libpq

2021-07-06 Thread Sudheer H R
It is not possible to use binary for some fields and text for some fields. If text format has to be used, it will be applicable for all fields. And this method involved converting to string format (sprint) on the server side and binary format from string (equivalent of sscanf), which is costly.

Re: Question about how to handle numeric (decimal) data types while using libpq

2021-07-06 Thread Dmitry Igrishin
On Tue, Jul 6, 2021, 14:04 Sudheer H R wrote: > Hello, > > I am trying to use libpq for interfacing with PostgreSQL from a C/C++ > based application. > > I have tried to use binary format of data for both sending and receiving > data to and from server (resultFormat = 1). > > As I understand

Question about how to handle numeric (decimal) data types while using libpq

2021-07-06 Thread Sudheer H R
Hello, I am trying to use libpq for interfacing with PostgreSQL from a C/C++ based application. I have tried to use binary format of data for both sending and receiving data to and from server (resultFormat = 1). As I understand most binary types, int, float etc… are encoded in bing-endian

Re: When to REINDEX a serial key?

2021-07-06 Thread David Rowley
On Tue, 6 Jul 2021 at 21:35, Ron wrote: > The legacy RDBMS which I used to manage has a tool for analyzing (not in the > Postgresql meaning of the word) an index, and displaying a histogram of how > many layers deep various parts of an index are. Using that histogram, you > can tell whether

When to REINDEX a serial key?

2021-07-06 Thread Ron
Server: RDS Postgresql 12.5 Client: Vanilla Postgresql 12.5 Like most systems, we have lots of tables indexed on sequences. Thus, all new keys are inserted into the "lower right hand corner" of the b-tree. The legacy RDBMS which I used to manage has a tool for analyzing (*not* in the

Re: The Curious Case of the Table-Locking UPDATE Query

2021-07-06 Thread hubert depesz lubaczewski
On Mon, Jul 05, 2021 at 08:22:39PM -0300, Emiliano Saenz wrote: > We have a huge POSTGRES 9.4 database in the production environment (several > tables have more than 100.000.00 registers). Last two months we have had > problems with CPU utilization. Debugging the locks (on pg_locks) we notice >