| From: | "Neil Conway" <nrc(at)cs(dot)berkeley(dot)edu> |
|---|---|
| To: | "Jeff Davis" <pgsql(at)j-davis(dot)com> |
| Cc: | "Josh Berkus" <josh(at)agliodbs(dot)com>, "Steve Atkins" <steve(at)blighty(dot)com>, "SF PostgreSQL" <sfpug(at)postgresql(dot)org> |
| Subject: | Re: IN question |
| Date: | 2008-12-11 00:11:32 |
| Message-ID: | b4e5ce320812101611x3b653f8cq9d758b52ddadbadf@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | sfpug |
On Wed, Dec 10, 2008 at 3:39 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> And if it's additional memory, it should probably be a different GUC.
Measuring the limit in bytes makes no sense, anyway.
> If there is an explicit limit, which sounds reasonable, I think it's
> good to separate parsing limits from executor limits.
IMHO this would not be very useful: should we also reject queries with
more than k WHERE clauses, FROM elements, or string literals longer
than k bytes? I think the time would be better spent working on
developing proper support for resource limits / quotas.
Neil
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2008-12-11 01:01:40 | Re: IN question |
| Previous Message | Jeff Davis | 2008-12-10 23:44:45 | Re: IN question |