From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Cc: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tobias Brox <tobias(at)nordicbet(dot)com>, Chris Browne <cbbrowne(at)acm(dot)org> |
Subject: | Re: Simple join optimized badly? |
Date: | 2006-10-10 17:28:29 |
Message-ID: | 200610101028.30191.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jim,
> We've depricated things before, I'm sure we'll do it again. Yes, it's a
> pain, but it's better than not having anything release after release.
> And having a formal hint language would at least allow us to eventually
> clean up some of these oddball cases, like the OFFSET 0 hack.
>
> I'm also not convinced that even supplimental statistics will be enough
> to ensure the planner always does the right thing, so query-level hints
> may have to stay (though it'd be great if that wasn't the case).
"stay"? I don't think that the general developers of PostgreSQL are going
to *accept* anything that stands a significant chance of breaking in one
release. You have you challange for the EDB development team: come up
with a hinting language which is flexible enough not to do more harm than
good (hint: it's not Oracle's hints).
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Tobias Brox | 2006-10-10 17:49:55 | Re: long running transactions |
Previous Message | Tom Lane | 2006-10-10 17:18:27 | Re: long running transactions |