On Fri, Dec 25, 2015 at 12:31 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello, > > At Thu, 24 Dec 2015 18:31:42 -0500, Corey Huinker <corey.huin...@gmail.com> > wrote in <CADkLM= > fh+zueykccdu8p0pproyywlep5obrjkce5o7swqdf...@mail.gmail.com> > > On Wed, Dec 23, 2015 at 3:08 PM, Jim Nasby <jim.na...@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 > > > Ok, I'll see what debug-level messages reveal.
