Re: Upgrade from Fedora 40 to Fedora 42, or from PostgreSQL 16.3 to PostgreSQL 16.9

2025-07-20 Thread Michael J. Baars
On Sun, Jul 20, 2025 at 10:13 AM Michael J. Baars wrote: > > On Sat, Jul 19, 2025 at 5:36 PM Tom Lane wrote: > > > > "Michael J. Baars" writes: > > > Compiling from source with a default ./configure --prefix=/usr/local > > > solves the problem. &g

Re: Upgrade from Fedora 40 to Fedora 42, or from PostgreSQL 16.3 to PostgreSQL 16.9

2025-07-20 Thread Michael J. Baars
On Sat, Jul 19, 2025 at 5:36 PM Tom Lane wrote: > > "Michael J. Baars" writes: > > Compiling from source with a default ./configure --prefix=/usr/local > > solves the problem. > > Cool. I confess I have no idea what the triggering difference > was, because t

Re: Upgrade from Fedora 40 to Fedora 42, or from PostgreSQL 16.3 to PostgreSQL 16.9

2025-07-19 Thread Michael J. Baars
On Fri, Jul 18, 2025 at 4:09 PM Tom Lane wrote: > > "Michael J. Baars" writes: > > Somewhere in between release 16.3 and > > release 16.9, changes must have been implemented that make the execution > > engine about two times slower than it was. > > That

Re: Upgrade from Fedora 40 to Fedora 42, or from PostgreSQL 16.3 to PostgreSQL 16.9

2025-07-19 Thread Michael J. Baars
On Fri, Jul 18, 2025 at 4:09 PM Tom Lane wrote: > > "Michael J. Baars" writes: > > Somewhere in between release 16.3 and > > release 16.9, changes must have been implemented that make the execution > > engine about two times slower than it was. > > That

Re: Lossless transmission of double precision floating point

2025-07-19 Thread Michael J. Baars
On Fri, Jul 18, 2025 at 4:12 PM Tom Lane wrote: > > "Michael J. Baars" writes: > > I receive data from a data provider on a daily basis, and noticed how they > > use fixed type floating point in text mode, to transmit data. As you might > > know, this type of tr

Upgrade from Fedora 40 to Fedora 42, or from PostgreSQL 16.3 to PostgreSQL 16.9

2025-07-18 Thread Michael J. Baars
Hello fellow PostgreSQL users and developers, I installed a new Fedora release last week and ran into a peculiar problem: Each night I need to run computations through about 70.000 rows and using release 16.3 that took about 4 hours to complete, but using release 16.9 the same computations now ta

Lossless transmission of double precision floating point

2025-07-18 Thread Michael J. Baars
Hi, I receive data from a data provider on a daily basis, and noticed how they use fixed type floating point in text mode, to transmit data. As you might know, this type of transmission is not lossless. Because the PostgreSQL binary format is not very portable across different database providers,

Lossless transmission of double precision floating point

2025-07-18 Thread Michael J. Baars
Hi, I receive data from a data provider on a daily basis, and noticed how they use fixed type floating point in text mode, to transmit data. As you might know, this type of transmission is not lossless. Because the PostgreSQL binary format is not very portable across different database providers,

Password reset link / 'less' does not exit in psql version 13.4

2022-07-25 Thread Michael J. Baars
Hello, I have two very simple questions: 1) I have an account at postgresql.org, but a link to a 'forgot password' seems to be missing on the login page. I have my password stored only on an old Fedora 32 computer. To change the password when logged in, you need to supply the old password. In s

Re: SSL compression

2021-11-08 Thread Michael J. Baars
On Mon, 2021-11-08 at 10:20 +0100, Magnus Hagander wrote: > On Mon, Nov 8, 2021 at 10:11 AM Michael J. Baars > wrote: > > On Mon, 2021-11-08 at 13:30 +0530, Abhijit Menon-Sen wrote: > > > > > At 2021-11-08 08:41:42 +0100, mjbaars1977.pgsql.hack...@gmail.com wrote:

Re: SSL compression

2021-11-08 Thread Michael J. Baars
On Mon, 2021-11-08 at 13:30 +0530, Abhijit Menon-Sen wrote: > At 2021-11-08 08:41:42 +0100, mjbaars1977.pgsql.hack...@gmail.com wrote: > > Could someone please explain to me, why compression is being > > considered unsafe / insecure? > > https://en.wikipedia.org/wiki/CRIME > Well Abhijit, person

SSL compression

2021-11-07 Thread Michael J. Baars
Hi All, While I was searching for methods to send the result of a query to the other side of the world, because it might be nice to go there once in a while, I noticed my best option, SSL compression, has been disabled as of version 14. Could someone please explain to me, why compression is bei

Re: Postgresql network transmission overhead

2021-02-25 Thread Michael J. Baars
On Wed, 2021-02-24 at 19:18 -0600, Justin Pryzby wrote: > On Wed, Feb 24, 2021 at 09:14:19AM +0100, Michael J. Baars wrote: > > I've written this function to insert several rows at once, and noticed a > > certain postgresql overhead as you can see from the log file. A lot

Postgresql network transmission overhead

2021-02-24 Thread Michael J. Baars
Hi, I've written this function to insert several rows at once, and noticed a certain postgresql overhead as you can see from the log file. A lot more data than the user data is actually sent over the net. This has a certain noticeable impact on the user transmission speed. I noticed that a lib

Re: computing dT from an interval

2021-02-23 Thread Michael J. Baars
On Mon, 2021-02-22 at 10:52 -0500, Tom Lane wrote: > "Michael J. Baars" writes: > > So how do you compute the number of seconds in 8 years? > > IMO, that's a meaningless computation, because the answer is not fixed. > Before you claim otherwise, think about th

Re: computing dT from an interval

2021-02-22 Thread Michael J. Baars
On Sat, 2021-02-20 at 11:20 -0500, Tom Lane wrote: > "Michael J. Baars" writes: > > Can someone please tell me which of these two queries gives the correct > > result and which one the incorrect? > > // 2.922 (&) > > with A1 as ( select make_inte

computing dT from an interval

2021-02-20 Thread Michael J. Baars
Hi, Can someone please tell me which of these two queries gives the correct result and which one the incorrect? /* * * * * dT in days for 1000 samples */ // 2.922 (&) with A1 as ( select make_interval (0, 0, 0, 0, 0, 0, ( extract ( epoch from interval '8 years' ) / 1000 ) ) as "00"