Skip site navigation (1) Skip section navigation (2)

Re: SQL/MED estimated time of arrival?

From: Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>
To: Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Eric Davies <eric(at)barrodale(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQL/MED estimated time of arrival?
Date: 2010-11-06 07:04:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2010/11/5 Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>:
> On Fri, 5 Nov 2010 16:27:49 +0900
> Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> wrote:
>> PL/Proxy has a similar functionality with RUN ON ALL to start queries
>> in parallel. So, I think it's a infrastructure commonly required.
> I noticed the lack of consideration about cache invalidation from
> reading PL/Proxy source, thanks for your mention about PL/Proxy. :-)

And if we really make this async query come true, I suggest designing
resource (i.e. remote connection) management very carefully. When the
executor fails in the middle of its execution, it possibly fails to
release its own resource; close() in ExecutorEnd() will never be
called. As far as I know files and memory are released automatically
in the current mechanism, but MED APIs will use their own resources
other than them.


Hitoshi Harada

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-11-06 07:21:44
Subject: Re: "Make" versus effective stack limit in regression tests
Previous:From: Rob WultschDate: 2010-11-06 03:28:24
Subject: Re: How can we tell how far behind the standby is?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group