Re: Selecting large tables gets killed

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

In response to

Responses

Browse pgsql-hackers by date

  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