| From: | Marko Kreen <markokr(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>, greg(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, mmoncure(at)gmail(dot)com, shigeru(dot)hanada(at)gmail(dot)com |
| Subject: | Re: Speed dblink using alternate libpq tuple storage |
| Date: | 2012-04-04 21:18:44 |
| Message-ID: | CACMqXC+T6au3zHZBnnYNnSHogqXEXNYhBjE-+00PQsQmeuGBjA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 4, 2012 at 10:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Given the lack of consensus around the suspension API, maybe the best
> way to get the underlying libpq patch to a committable state is to take
> it out --- that is, remove the "return zero" option for row processors.
> Since we don't have a test case for it in dblink, it's hard to escape
> the feeling that we may be expending a lot of effort for something that
> nobody really wants, and/or misdesigning it for lack of a concrete use
> case. Is anybody going to be really unhappy if that part of the patch
> gets left behind?
Agreed.
--
marko
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro HORIGUCHI | 2012-04-04 22:04:18 | Re: Speed dblink using alternate libpq tuple storage |
| Previous Message | Andrew Dunstan | 2012-04-04 21:07:31 | Re: log chunking broken with large queries under load |