Re: view reading information_schema is slow in PostgreSQL 12
От | David Rowley |
---|---|
Тема | Re: view reading information_schema is slow in PostgreSQL 12 |
Дата | |
Msg-id | CAApHDvrj9b3OrDt_Yc-21LUF23_hd=Ni5o856xXGidaQtQ__GQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: view reading information_schema is slow in PostgreSQL 12 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: view reading information_schema is slow in PostgreSQL 12
|
Список | pgsql-performance |
On Sat, 13 Jun 2020 at 16:07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > David Rowley <dgrowleyml@gmail.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
В списке pgsql-performance по дате отправления: