I've investigated further and found out that the code that processes
SQL functions is completely different from the code that processes SQL
statements. The latter is more efficient, and there is ongoing work to
merge both.
Currently, in the SQL function path the plan is always generic. The
planner
On 3/28/25 12:38, Sasa Vilic wrote:
Hello,
Please excuse my ignorance, because I might be missing something
obvious, but how is this not a bug?
I simply open 2 terminals and connect to the same database.
**TERMINAL 1:**
sasa=# create table tst1(id int primary key);
CREATE TABLE
sasa=# inser
On Fri, Mar 28, 2025 at 12:39 PM Sasa Vilic wrote:
>
> Hello,
>
> Please excuse my ignorance, because I might be missing something obvious, but
> how is this not a bug?
>
> I simply open 2 terminals and connect to the same database.
>
> **TERMINAL 1:**
>
> sasa=# create table tst1(id int primary
Hello,
Please excuse my ignorance, because I might be missing something obvious,
but how is this not a bug?
I simply open 2 terminals and connect to the same database.
**TERMINAL 1:**
sasa=# create table tst1(id int primary key);
CREATE TABLE
sasa=# insert into tst1(id) values(1);
INSERT 0 1
sa
On Fri, Mar 28, 2025 at 9:24 AM Ron Johnson wrote:
>
> "at least for WHERE conditions that are selective" confuses me. Aren't
> _all_ WHERE clauses selective?
>
>
>From earlier in the email, selectivity is a scale, the wording here implies
"has a meaningful selectivity".
"Fundamentally yes, but
On Fri, Mar 28, 2025 at 10:02 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> Selectivity is evaluating cardinality with an eye on the frequency of
> the values you are actually going to be filtering on. So low cardinality
> booleans can be highly selective in usage if you are looking
On 23/03/2025 2:35 pm, David Rowley wrote:
>> alter table entity_2 add column new_column text;
> Is this just an example command? You can't add a column to a
> partition directly.
Yes, it was just the simplest way I could think of to take an exclusive
lock. But on this note: I guess it takes a lo
On Fri, Mar 28, 2025 at 9:35 AM Laurenz Albe
wrote:
> On Fri, 2025-03-28 at 13:38 +0100, Moreno Andreo wrote:
> > Postgres 16.4 (planning to go on 17.4)
> > I'm creating some indexes based on some slow query reported by logs.
> > These queries involve a WHERE with more than 5 fields, that are
On Fri, 2025-03-28 at 13:38 +0100, Moreno Andreo wrote:
> Postgres 16.4 (planning to go on 17.4)
> I'm creating some indexes based on some slow query reported by logs.
> These queries involve a WHERE with more than 5 fields, that are matching by
> =, <>, LIKE and IN()
> I read that equality
Hi,
Postgres 16.4 (planning to go on 17.4)
I'm creating some indexes based on some slow query reported by logs.
These queries involve a WHERE with more than 5 fields, that are matching
by =, <>, LIKE and IN()
I read that equality fields must be first, then the others.
Is it correct?
Based on th
Hi,
[code]
SELECT current_setting('server_version_num')::int > 13 as v13
\gset
\if :v13
CREATE OR REPLACE TRIGGER playersinleague_insert AFTER INSERT ON
playersinleague WHEN new.current_rank IS NULL
BEGIN
UPDATE playersinleague SET current_rank = 1 + (SELECT
coalesce( max( cur
El día lunes, marzo 24, 2025 a las 07:27:21a. m. +0100, Laurenz Albe escribió:
> On Mon, 2025-03-24 at 06:57 +0100, Matthias Apitz wrote:
> > El día lunes, febrero 24, 2025 a las 12:41:05p. m. +0100, Laurenz Albe
> > escribió:
> > > Perhaps I need not say that, but ALTER COLLATION ... REFRESH VER
On Fri, 2025-03-28 at 07:37 +0100, Matthias Apitz wrote:
> Anyway, does it make sense to ALTER COLLATION in these databases as well?
> >
> > I would say so, yes. At least on the template you are using for new
> > databases.
>
> $ psql -Upostgres template0
> Passwort für Benutzer postgres:
> psq
13 matches
Mail list logo
