Re: why partition pruning doesn't work?
От | Robert Haas |
---|---|
Тема | Re: why partition pruning doesn't work? |
Дата | |
Msg-id | CA+TgmoZcHQK+sD5yJrWU6vnZ_x5RaYyLtNP_tUUcrUhRorz=9A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: why partition pruning doesn't work? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: why partition pruning doesn't work?
|
Список | pgsql-hackers |
On Sun, Jul 15, 2018 at 1:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > What we'd be better off doing, if we go this route, is to install an > assertion-build-only test that verifies during relation_open(NoLock) > that some kind of lock is already held on the rel. That would protect > not only the executor, but a boatload of existing places that open > rels with NoLock on the currently-unverified assumption that a lock is > already held. +1. In fact, maybe we ought to go a little further and have a relation_reopen(oid, mode) that verifies that a lock in the specified mode is held. And then maybe we ought to go even further and start trying to get rid of all the places where we reopen already-opened relations. A distressing number of new patches add more places that do that, and while I try to push back on those, I think they are proliferating, and I think that they are not free. Granted, a hash table lookup is pretty cheap, but if you do a sufficient number of them in commonlt-taken code paths, it's got to cost something. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: