DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=bf/+VQSU2JspQ/khSjk5tnFAMVqbHoPHlaxgdFhnB7pzbFl9cNtIjaKkpxKj6OG1EnFIIxdT9zDJx2d7alDDLWiF8tgrHkZQW7Tt4I7zK6TYb8OdyB3QrhxR2MN9xD3s9KqmE8SiObngKrBLRiCjJfJgXGORuyHXBqVYjNgeetw=
Message-ID: <c2d9e70e0512160645q20ca27b7ja2f1235bed797747@mail.gmail.com>
Date: Fri, 16 Dec 2005 09:45:34 -0500
From: Jaime Casanova <systemguards@gmail.com>
To: Kyle Cordes <kyle@kylecordes.com>
Subject: Re: Overriding the optimizer
Cc: pgsql-performance@postgresql.org
In-Reply-To: <43A2CCEF.9030605@kylecordes.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <200512141603.52583.blargity@gmail.com>
	<1134629567.14248.27.camel@firebolt>
	<200512150148.16125.blargity@gmail.com>
	<1134644526.14248.60.camel@firebolt>
	<43A1C40D.8040006@paradise.net.nz> <43A1F6DB.3080805@modgraph-usa.com>
	<43A226E7.7040508@paradise.net.nz> <43A22BE3.6020103@modgraph-usa.com>
	<20051216052025.GB691@filer> <43A2CCEF.9030605@kylecordes.com>

On 12/16/05, Kyle Cordes <kyle@kylecordes.com> wrote:
> Kevin Brown wrote:
>
> >Craig A. James wrote:
> >
> >
> >>Hints are dangerous, and I consider them a last resort.
> >>
> >>
> >
> >If you consider them a last resort, then why do you consider them to
> >be a better alternative than a workaround such as turning off
> >enable_seqscan, when all the other tradeoffs are considered?
> >
> >
>
> I would like a bit finer degree of control on this - I'd like to be able
> to tell PG that for my needs, it is never OK to scan an entire table of
> more than N rows.  I'd typically set N to 1,000,000 or so.  What I would
> really like is for my DBMS to give me a little more pushback - I'd like
> to ask it to run a query, and have it either find a "good" way to run
> the query, or politely refuse to run it at all.
>
> Yes, I know that is an unusual request  :-)
>
> The context is this - in a busy OLTP system, sometimes a query comes
> through that, for whatever reason (foolishness on my part as a
> developer, unexpected use by a user, imperfection of the optimizer,
> etc.), takes a really long time to run, usually because it table-scans
> one or more large tables.  If several of these happen at once, it can
> grind an important production system effectively to a halt.  I'd like to
> have a few users/operations get a "sorry, I couldn't find a good way to
> do that" message, rather than all the users find that their system has
> effectively stopped working.
>
> Kyle Cordes
> www.kylecordes.com
>
>

set statement_timeout in postgresql.conf

--
Atentamente,
Jaime Casanova
(DBA: DataBase Aniquilator ;)