Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: IN question
- 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: Wed, 10 Dec 2008 16:11:32 -0800
- Message-id: <b4e5ce320812101611x3b653f8cq9d758b52ddadbadf@mail.gmail.com> <text/plain>
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
- Follow-Ups:
- Re: IN question
- From: Jeff Davis
- Re: IN question
- References:
- IN question
- From: Eric Walstad
- Re: IN question
- From: Meredith L. Patterson
- Re: IN question
- From: Mat Caughron
- Re: IN question
- From: Steve Atkins
- Re: IN question
- From: Josh Berkus
- Re: IN question
- From: Jeff Davis
- IN question
- Prev by Date: Re: IN question
- Next by Date: Re: IN question
- Previous by thread: Re: IN question
- Next by thread: Re: IN question
- Indexes: