From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marti Raudsepp <marti(at)juffo(dot)org> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, amul sul <sul_amul(at)yahoo(dot)co(dot)in>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Selecting large tables gets killed |
Date: | 2014-02-20 14:51:47 |
Message-ID: | 26679.1392907907@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marti Raudsepp <marti(at)juffo(dot)org> writes:
> On Thu, Feb 20, 2014 at 12:07 PM, Ashutosh Bapat
> <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
>> That seems a good idea. We will get rid of FETCH_COUNT then, wouldn't we?
> No, I don't think we want to do that. FETCH_COUNT values greater than
> 1 are still useful to get reasonably tabulated output without hogging
> too much memory.
Yeah. The other reason that you can't just transparently change the
behavior is error handling: people are used to seeing either all or
none of the output of a query. In single-row mode that guarantee
fails, since some rows might get output before the server detects
an error.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2014-02-20 15:10:47 | Re: WAL Rate Limiting |
Previous Message | Simon Riggs | 2014-02-20 14:43:53 | Re: WAL Rate Limiting |