Re: why partition pruning doesn't work?
От | David Rowley |
---|---|
Тема | Re: why partition pruning doesn't work? |
Дата | |
Msg-id | CAKJS1f_ZoH6vJwpiFt4EvE+BuCoDE=hLJZ_9o0TZfkrVXxpSRQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: why partition pruning doesn't work? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: why partition pruning doesn't work?
Re: why partition pruning doesn't work? |
Список | pgsql-hackers |
On 16 July 2018 at 12:12, Robert Haas <robertmhaas@gmail.com> wrote: > 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. Wouldn't it be better to just store the Relation indexed by its relid somewhere the first time we opened it? Then just do a direct array lookup on that rather than looking up by hashtable in syscache? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: