Re: [HACKERS] Mini improvement: statement_cost_limit

hello ...

>
> I still support it. Regrettably, many SQL developers introduce product
> joins and other unintentional errors. Why let problem queries through?

i think the killer is that we don't have to wait until the query dies
with a statement_timeout.
it is ways more elegant to kill things before they have already eaten
too many cycles.
one thing which is important as well: statement_cost_limit does not
kill queries which have just been waiting for a lock.
this makes things slightly more predictable.

> Security-wise they're great Denial of Service attacks, bringing the
> server to its knees better than most ways I know, in conjunction
> with a
> nice hefty work_mem setting. 27 table product joins: memory, CPU, I/O
> and diskspace resources used all in a simple killer query.
>

i am not too concerned about DNS, i have to admit.
i would rather see it as a way to make developers do better things.

> If anybody thinks costs are inaccurate, don't use it. Or better still
> improve the cost models. It isn't any harder or easier to find a
> useful
> value than it is to use statement_timeout. What's the difference
> between
> picking an arbitrary time and an arbitrary cost? You need to alter the
> value according to people's complaints in both cases.

the cost model is good enough to see if something is good or bad.
this is basically all we want to do here --- killing all evil.

> *snip*

>
>
> A compromise would be to have log_min_statement_cost (or
> warn_min_statement_cost) which will at least help find these
> problems in
> testing before we put things live, but that still won't help with
> production issues.
>

definitely. a good idea as well - but people will hardly read it, i
guess :(.

> Another alternative would be to have a plugin that can examine the
> plan
> immediately after planner executes, so you can implement this
> yourself,
> plus some other possibilities.
>

this would be really fancy.
how could a plugin like that look like?

hans

--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: www.postgresql-support.de

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers