Re: [POC] FETCH limited by bytes. - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: [POC] FETCH limited by bytes.
Date
Msg-id 20151225.143159.264144927.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: [POC] FETCH limited by bytes.  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: [POC] FETCH limited by bytes.
List pgsql-hackers
Hello,

At Thu, 24 Dec 2015 18:31:42 -0500, Corey Huinker <corey.huinker@gmail.com> wrote in
<CADkLM=fh+ZUEykcCDu8P0PPrOyYwLEp5OBRjKCe5O7swqDF65w@mail.gmail.com>
> On Wed, Dec 23, 2015 at 3:08 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> 
> > On 12/23/15 12:15 PM, Corey Huinker wrote:
> >
> >> That's fair. I'm still at a loss for how to show that the fetch size was
> >> respected by the remote server, suggestions welcome!
> >>
> >
> > A combination of repeat() and generate_series()?
> >
> > I'm guessing it's not that obvious and that I'm missing something; can you
> > elaborate?
> > --
> > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> > Experts in Analytics, Data Architecture and PostgreSQL
> > Data in Trouble? Get it in Treble! http://BlueTreble.com
> >
> 
> 
> I'll try. So the basic test of whether the FDW respected the fetch limit is
> this:
> 
> 1. create foreign server using postgres_fdw, create foreign table.
> 2. run a query against that table. it works. great.
> 3. alter server set fetch size option to 101 (or any number different from
> 100)
> 4. run same query against the table. the server side should show that the
> result set was fetched in 101 row chunks[1].
> 5. alter table set fetch size option to 102 (or any number different from
> 100 and the number you picked in #3)
> 6. run same query against the table. the server side should show that the
> result set was fetched in 102 row chunks[1].
> 
> The parts marked [1] are the problem...because the way I know it works is
> looking at the query console on the remote redshift cluster where the query
> column reads "FETCH 101 in c1" or somesuch rather than the query text.
> That's great, *I* know it works, but I don't know how capture that
> information from a vanilla postgres server, and I don't know if we can do
> the regression with a loopback connection, or if we'd need to set up a
> second pg instance for the regression test scaffolding.

I believe it won't be needed as a regression test but DEBUGn
messages could be usable to see "what was sent to the remote
side". It can be shown to the console so easily done in
regression test. See the deocumentation for client_min_messages
for details. (It could receive far many messages then expected,
though, and maybe fragile for changing in other part.)

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center





pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: pgbench - allow backslash-continuations in custom scripts
Next
From: Amit Langote
Date:
Subject: MergeAttributes type (mod) conflict error detail