On Thu, Oct 30, 2014 at 2:28 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 30 October 2014 04:24, Amit Kapila <amit.kapil...@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. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
