Re: view reading information_schema is slow in PostgreSQL 12

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: regrog <andrea(dot)vencato(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: view reading information_schema is slow in PostgreSQL 12
Date: 2020-06-13 07:52:44
Message-ID: CAApHDvrj9b3OrDt_Yc-21LUF23_hd=Ni5o856xXGidaQtQ__GQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sat, 13 Jun 2020 at 16:07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > I wondered if it would be more simple to add some smarts to look a bit
> > deeper into case statements for selectivity estimation purposes. An
> > OpExpr like:
> > CASE c.contype WHEN 'c' THEN 'CHECK' WHEN 'f' THEN 'FOREIGN KEY' WHEN
> > 'p' THEN 'PRIMARY KEY' WHEN 'u' THEN 'UNIQUE' END = 'CHECK';
>
> Hm. Maybe we could reasonably assume that the equality operators used
> for such constructs are error-and-side-effect-free, thus dodging the
> semantic problem I mentioned in the other thread?

I'm only really talking about selectivity estimation only for now.
I'm not really sure why we'd need to ensure that the equality operator
is error and side effect free. We'd surely only be executing the case
statement's operator's oprrest function? We'd need to ensure we don't
invoke any casts that could error out.

David

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message David Rowley 2020-06-13 08:22:09 Re: view reading information_schema is slow in PostgreSQL 12
Previous Message Pavel Stehule 2020-06-13 05:23:04 Re: view reading information_schema is slow in PostgreSQL 12