Re: why do we need create tuplestore for each fetch?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: 高增琦 <pgf00a(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: why do we need create tuplestore for each fetch?
Date: 2011-12-19 13:06:04
Message-ID: CA+TgmobFc9iojpEXCvCkJKhJ6-Sj3cc2=snOj0b0o3QUfkqeRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 15, 2011 at 8:30 AM, 高增琦 <pgf00a(at)gmail(dot)com> wrote:
> I found this several days ago when I try to debug a "fetch" of cursor.
> And I have sent a mail to this list, but no one reply...
> Maybe this is a very simple problem, please help me, thanks a lot...
>
> Here is the example:
>     create table t (a int);
>     insert into t values (1),(3),(5),(7),(9);
>     insert into t select a+1 from t;
>     begin;
>     declare c cursor for select * from t order by a;
>     fetch 3 in c;
>     fetch 3 in c;
>     fetch 3 in c;
>
> In 'PortalRun', a fetch stmt will be treated with PORTAL_UTIL_SELECT,
> and then a tuplestore will be created in 'FillPortalStore' in the
> fetch stmt's portal.
>
> In 'FillPortalStore', all result will be store at that tuplestore,
> Then, go back to 'PortalRun'; next,  'PortalRunSelect' will send this
> results to client...
>
> My problem is: why do we need create that tuplestore as an
> middle storeage? why do not we just send these result to clent
> at the first time?

Good question. I wouldn't expect it to matter very much for a
three-row fetch, but maybe it does for larger ones? What is your
motivation for investigating this?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-12-19 13:13:04 Re: Review: Non-inheritable check constraints
Previous Message Robert Haas 2011-12-19 12:50:10 Re: Page Checksums