Re: Hints proposal

From: Csaba Nagy <nagy(at)ecircle-ag(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Hints proposal
Date: 2006-10-12 17:15:40
Message-ID: 1160673340.28751.83.camel@coppola.muc.ecircle.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

> I'm not suggesting that we do that, but it seems better then embedding
> the hints in the queries themselves.

OK, what about this: if I execute the same query from a web client, I
want the not-so-optimal-but-safe plan, if I execute it asynchronously, I
let the planner choose the
best-overall-performance-but-sometimes-may-be-slow plan ?

What kind of statistics/table level hinting will get you this ?

I would say only query level hinting will buy you query level control.
And that's perfectly good in some situations.

I really can't see why a query-level hinting mechanism is so evil, why
it couldn't be kept forever, and augmented with the possibility of
correlation hinting, or table level hinting.

These are really solving different problems, with some overlapping...

Cheers,
Csaba.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-10-12 17:18:17 Re: [HACKERS] Hints proposal
Previous Message Tom Lane 2006-10-12 17:07:48 Re: Getting the type Oid in a CREATE TYPE output function

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2006-10-12 17:18:17 Re: [HACKERS] Hints proposal
Previous Message Csaba Nagy 2006-10-12 17:04:46 Re: [HACKERS] Hints proposal