Message-ID: <b6b22f2c59a0dede4271bec0deeb85efcb85abb2.camel@cybertec.at>
Subject: Re: 15x slower PreparedStatement vs raw query
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Alex <cdalxndr@yahoo.com>, Rick Otten <rottenwindfish@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, "pgsql-performa."
	 <pgsql-performance@postgresql.org>
Date: Tue, 04 May 2021 17:22:04 +0200
In-Reply-To: <6cd0e931a59e1.4c58a67a1e5f6@yahoo.com>
References: <3f8c88d8a6ef9.d82fa04cf610d.ref@yahoo.com>
	 <3f8c88d8a6ef9.d82fa04cf610d@yahoo.com>
	 <20210503201811.GA27406@telsasoft.com>
	 <49daf090ac5b1.96e1ada6021ee@yahoo.com>
	 <CAMAYy4JhWn+FhwhzHUWKiDy8r62Bw4eT5QVq=kQDYyjJheV4ag@mail.gmail.com>
	 <6cd0e931a59e1.4c58a67a1e5f6@yahoo.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/b6b22f2c59a0dede4271bec0deeb85efcb85abb2.camel%40cybertec.at>
Precedence: bulk

On Tue, 2021-05-04 at 13:59 +0000, Alex wrote:
> "Powerful general purpose relational database" but not smart... 

Too smart can easily become slow...

> I propose a feature to use information from previously executed queries to adjust the query plan time accordingly.
> Reusing the same generic plan may and will lead to very long execution times.

AI can go wrong too, and I personally would be worried that such cases
are very hard to debug...

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com