From: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Parallel INSERT SELECT take 2 |
Date: | 2021-05-10 06:46:54 |
Message-ID: | OS0PR01MB571619395D1F7B337D2B930594549@OS0PR01MB5716.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > When the parallel safety of some of these objects is changed, it's costly to
> reflect it on the parallel safety of tables that depend on them. So, we don't do
> it. Instead, we provide a utility function pg_get_parallel_safety('table_name')
> that returns records of (objid, classid, parallel_safety) that represent the
> parallel safety of objects that determine the parallel safety of the specified
> table. The function only outputs objects that are not parallel safe.
> > >
> >
> > So, users need to check count(*) for this to determine
> > parallel-safety? How about if we provide a wrapper function on top of
> > this function or a separate function that returns char to indicate
> > whether it is safe, unsafe, or restricted to perform a DML operation
> > on the table?
>
> Such wrapper function make sense.
Thanks for the suggestion, and I agree.
I will add another wrapper function and post new version patches soon.
Best regards,
houzj
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2021-05-10 06:47:19 | Re: Small issues with CREATE TABLE COMPRESSION |
Previous Message | tanghy.fnst@fujitsu.com | 2021-05-10 06:36:19 | RE: Remove "FROM" in "DELETE FROM" when using tab-completion |