From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Neil Conway <nrc(at)cs(dot)berkeley(dot)edu> |
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 01:01:40 |
Message-ID: | 1228957300.2754.104.camel@dell.linuxdev.us.dell.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | sfpug |
On Wed, 2008-12-10 at 16:11 -0800, Neil Conway wrote:
> 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.
>
Sure it does. If you're concerned about the application generating
infinite SQL strings and sending them to the server, a byte limit on the
SQL string would solve it.
After all, as Josh pointed out, there _is_ a limit measured in bytes:
available memory (and some operating systems don't handle that very
well).
Maybe we shouldn't add such a limit, but it at least makes sense.
> > 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.
>
I'm not suggesting we introduce a bunch of additional limits. I'm just
saying that if we introduce a scanner/parser limit (I'm not arguing
either way), I think it should be a separate GUC from work_mem.
I think you're right that this falls under the heading of resource
limits and quotas, and whatever we do should fit within some kind of
overall model.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2008-12-11 18:05:35 | Re: IN question |
Previous Message | Neil Conway | 2008-12-11 00:11:32 | Re: IN question |