Re: Display of multi-target-table Modify plan nodes in EXPLAIN

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Display of multi-target-table Modify plan nodes in EXPLAIN
Дата
Msg-id CAFjFpRfAg0fBVL7010keehhpi5zayqzEvwfbvPcHLm1X4Kot5A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Display of multi-target-table Modify plan nodes in EXPLAIN  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Display of multi-target-table Modify plan nodes in EXPLAIN  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Mon, Mar 23, 2015 at 10:51 AM, Tom Lane
<spandir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us" target="_blank">tgl@sss.pgh.pa.us</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><spanclass="">Ashutosh Bapat <<a
href="mailto:ashutosh.bapat@enterprisedb.com">ashutosh.bapat@enterprisedb.com</a>>writes:<br /> > On Sun, Mar 22,
2015at 6:32 AM, Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br /></span><span
class="">>>What I'm imagining instead is that when there's more than one<br /></span>>> target relation, we
produceoutput like ...<br /><span class=""><br /> > This looks better.<br /> > In the format above, you have
specifiedboth the Remote SQL for scan as<br /> > well as update but in the example you have only mentioned only
RemoteSQL<br /> > for update; it may be part of "... etc ...". It's better to provide both.<br /><br /></span>Hm? 
Wedon't have scan nodes that read more than one table, so I'm<br /> not following your point.<br /><br />              
         regards, tom lane<br /></blockquote></div><br /></div><div class="gmail_extra">In the format you specified<br
/>     Multi-Table Update<br />                 Relation Name: pt1  -- this is the *nominal* target<br />              
 Target Relations:<br />                   [<br />                     Relation Name: pt1  -- first actual target<br />
                   Schema: public<br />                     Alias: pt1<br />                   ]<br />                
 [<br />                     Relation Name: ft1<br />                     Schema: public<br />                    
Alias:ft1<br />                     Remote SQL: UPDATE ref1 ...<br />                   ]<br /><br />                
Plans:<br/>                   Plan: (seq scan on pt1 here)<br />                   Plan: (foreign scan on ft1 here)<br
/></div><divclass="gmail_extra">For relation ft1, there is an Update node as well as a scan node. Update node has
UpdateRemote SQL and Scan will have corresponding SELECT Remote SQL.<br /><br /></div><div class="gmail_extra">But in
thetext output you gave<br />Update on public.pt1  (cost=0.00..321.05 rows=3541 width=46)<br />    Update on
public.pt1<br/>    Foreign Update on public.ft1<br />      Remote SQL: UPDATE public.ref1 SET c1 = $2 WHERE ctid =
$1<br/>    Foreign Update on public.ft2<br />      Remote SQL: UPDATE public.ref2 SET c1 = $2 WHERE ctid = $1<br />  
 Updateon public.child3<br />    ->  Seq Scan on public.pt1  (cost=0.00..0.00 rows=1 width=46)<br />        
 Output:(pt1.c1 + 1), pt1.c2, pt1.c3, pt1.ctid<br />    ... etc ...<br /><br /></div><div class="gmail_extra">For ft1
thereis only Update Remote SQL. whereas for child3 you have specified the Seq Scan as well. I was wondering if the
foreignscan on ft1 is part of "...etc..."?. Further we have to make it clear which scan goes with which Update, either
bylisting the scans in the same order as updates or by associating each scan with corresponding update.<br clear="all"
/></div><divclass="gmail_extra"><br />-- <br /><div class="gmail_signature"><div dir="ltr">Best Wishes,<br />Ashutosh
Bapat<br/>EnterpriseDB Corporation<br />The Postgres Database Company<br /></div></div></div></div> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Table-level log_autovacuum_min_duration
Следующее
От: Abhijit Menon-Sen
Дата:
Сообщение: Re: Auditing extension for PostgreSQL (Take 2)