Re: group locking: incomplete patch, just for discussion
| От | Amit Kapila |
|---|---|
| Тема | Re: group locking: incomplete patch, just for discussion |
| Дата | |
| Msg-id | CAA4eK1JcC6s92ZMN70qQYStBbNrgzgqV8CmYginqDTTTFbUj9Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: group locking: incomplete patch, just for discussion (Simon Riggs <simon@2ndQuadrant.com>) |
| Ответы |
Re: group locking: incomplete patch, just for discussion
|
| Список | pgsql-hackers |
On Thu, Oct 30, 2014 at 2:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 30 October 2014 04:24, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> >> Locking the toast table of any main tables we access seems easily
> >> done. Though perhaps we should make weak locking of the toast table
> >> presumed. Do we have cases where the toast table can be accessed when
> >> the main table is not also strong locked first?
> >
> > I think it is possible to have a strong lock on toast table before
> > main table.
> > Cluster pg_toast.<toast_table_name> using <toast_index>;
> > Vacuum Full pg_toast.<toast_table_name>;
> > Reindex Index pg_toast.<toast_index_name>;
> > ..
> >
> > Now if take the lock on toast table in main task, it will block some of
> > the operations before actually they need to be blocked.
>
> Very strange.
>
> Those commands are not common operations? I doubt many people even
> know that exists.
>
> All of those commands would block SELECTs on the main table, so there
> is no significant benefit in that behaviour.
>
> In fact it would be more sensible to lock the toast table earlier.
>
> On 30 October 2014 04:24, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> >> Locking the toast table of any main tables we access seems easily
> >> done. Though perhaps we should make weak locking of the toast table
> >> presumed. Do we have cases where the toast table can be accessed when
> >> the main table is not also strong locked first?
> >
> > I think it is possible to have a strong lock on toast table before
> > main table.
> > Cluster pg_toast.<toast_table_name> using <toast_index>;
> > Vacuum Full pg_toast.<toast_table_name>;
> > Reindex Index pg_toast.<toast_index_name>;
> > ..
> >
> > Now if take the lock on toast table in main task, it will block some of
> > the operations before actually they need to be blocked.
>
> Very strange.
>
> Those commands are not common operations? I doubt many people even
> know that exists.
>
> All of those commands would block SELECTs on the main table, so there
> is no significant benefit in that behaviour.
>
> In fact it would be more sensible to lock the toast table earlier.
>
It might make some sense to lock the toast table earlier for this
particular case, but I don't think in general it will be feasible to lock
all the tables (including catalog tables) which might get used in the
overall operation before starting parallel operation. I believe it will
make doing parallel stuff difficult if we try to go via this route, as
we need to always do this for any operation we want to make parallel.
It will always have the risk that we might miss something and another
thing is it might not be feasible in all kind of cases.
If I understand correctly, you are suggesting that to get the first version
of parallel operation out earlier, we should try to avoid all the stuff
(like group locking, ...), have some restrictions on which kind of cases
Create Index can work, do some hackery in Create Index path to avoid
any kind of locking problems and do the parallel operation for External
Sort (which might avoid need for shared memory allocator) and then
call it a day and then do the things which we need for other parallel
operations as and when they are required. I think this might be a good
approach in itself if somebody wants to target something to release
early, however in medium to short term when we want to provide
non-trivial parallel operations we have to eventually solve those problems
and delaying will only make the things worse.
In short, I agree that there is a merit in your idea w.r.t getting the first
version of parallel operation out early, however if we see from medium
to long term, I feel solving group locking problem (or some other general
infrastructure what Robert mentioned upthread) can yield better results,
unless you feel that is not at all required for parallel operations.
В списке pgsql-hackers по дате отправления: