On Thu, Feb 10, 2011 at 7:32 PM, Craig James craig_ja...@emolecules.com wrote:
On 2/10/11 9:21 AM, Kevin Grittner wrote:
Shaun Thomasstho...@peak6.com wrote:
how difficult would it be to add that syntax to the JOIN
statement, for example?
Something like this syntax?:
JOIN WITH
Hi. I have the idea: hints joined to function. For example instead of
WHERE table1.field1=table2.field2
write:
WHERE specificeq(table1.field1,table2.field2)
and hints add to declaration of specificeq function.
2011/2/23, Robert Haas robertmh...@gmail.com:
On Wed, Feb 16, 2011 at 4:22 PM, Bruce
On Wed, Feb 16, 2011 at 4:22 PM, Bruce Momjian br...@momjian.us wrote:
I am not excited about the idea of putting these correlations in
queries. What would be more intesting would be for analyze to build a
correlation coeffficent matrix showing how columns are correlated:
a b c
Kevin Grittner wrote:
Shaun Thomas stho...@peak6.com wrote:
how difficult would it be to add that syntax to the JOIN
statement, for example?
Something like this syntax?:
JOIN WITH (correlation_factor=0.3)
Where 1.0 might mean that for each value on the left there was only
one
On Thu, Feb 10, 2011 at 9:25 AM, Chris Browne cbbro...@acm.org wrote:
robertmh...@gmail.com (Robert Haas) writes:
On Thu, Feb 10, 2011 at 11:45 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Well, I'm comfortable digging in my heels against doing *lame* hints
just because it's what all
I've wordsmithed Chris's changes some, and then spun off a completely
separate page for Hints discussion, since the NotToDo item was becoming
too long.
Something like this syntax?:
JOIN WITH (correlation_factor=0.3)
Please, NO!
This is exactly the kind of hint that I regard as a last resort
On Sun, Feb 13, 2011 at 3:29 PM, Josh Berkus j...@agliodbs.com wrote:
I've wordsmithed Chris's changes some, and then spun off a completely
separate page for Hints discussion, since the NotToDo item was becoming
too long.
Something like this syntax?:
JOIN WITH (correlation_factor=0.3)
On Sun, Feb 13, 2011 at 10:49 PM, Josh Berkus j...@agliodbs.com wrote:
I fail to see how 1 through 3 can tell the planner the correlation
between two fields in two separate tables.
CREATE CORRELATION_ESTIMATE ( table1.colA ) = ( table2.colB ) IS 0.3
... and then it fixes the correlation for
2011/2/10 Tobias Brox tobi...@gmail.com
On 4 February 2011 04:46, Josh Berkus j...@agliodbs.com wrote:
Optimizer hints are used to work around problems in the optimizer and
introduce upgrade and maintenance issues. We would rather have the
problems reported and fixed. We have discussed a
2011/2/11 Віталій Тимчишин tiv...@gmail.com:
If the list is hard-coded, you can create partial index on
account_transaction(account_id, created desc) where trans_type_id in ( ...
long, hard-coded list ...)
My idea as well, though it looks ugly and it would be a maintenance
head-ache
11.02.11 11:29, Tobias Brox написав(ла):
2011/2/11 Віталій Тимчишинtiv...@gmail.com:
If the list is hard-coded, you can create partial index on
account_transaction(account_id, created desc) where trans_type_id in ( ...
long, hard-coded list ...)
My idea as well, though it looks ugly and it
2011/2/11 Vitalii Tymchyshyn tiv...@gmail.com:
My idea as well, though it looks ugly and it would be a maintenance
head-ache (upgrading the index as new transaction types are added
would mean costly write locks on the table,
Create new one concurrently.
Concurrently? Are there any ways to
On 02/11/2011 12:26 PM, Tobias Brox wrote:
2011/2/11 Vitalii Tymchyshyntiv...@gmail.com:
My idea as well, though it looks ugly and it would be a maintenance
head-ache (upgrading the index as new transaction types are added
would mean costly write locks on the table,
Create new one
select * from account_transaction where trans_type_id in ( ...
long, hard-coded list ...) and account_id=? order by created desc
limit 25;
You could use an index on (account_id, created, trans_type), in
replacement of your index on (account_id, created). This will not prevent
the Index
On Thu, Feb 3, 2011 at 8:46 PM, Josh Berkus j...@agliodbs.com wrote:
Optimizer hints are used to work around problems in the optimizer and
introduce upgrade and maintenance issues. We would rather have the
problems reported and fixed. We have discussed a more sophisticated
system of per-class
Robert Haas robertmh...@gmail.com wrote:
I think it's just dumb to say we don't want hints. We want hints,
or at least many of us do.
Well, yeah. Even those most ostensibly opposed to hints have been
known to post that they would rather not have the optimizer
recognize two logically
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com wrote:
I don't know exactly what the right solution is off the top of my
head, but digging in our heels is not it.
Well, I'm comfortable digging in my heels against doing *lame* hints
just because it's what
On Thu, Feb 10, 2011 at 11:45 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Well, I'm comfortable digging in my heels against doing *lame* hints
just because it's what all the other kids are doing, which I think
is the only thing which would have satisfied the OP on this thread.
From
On 02/10/2011 10:45 AM, Kevin Grittner wrote:
Even there I would tend to think that the sort of do it this way
hints that people seem to initially want wouldn't be good; it should
be a way to override the costing factor which the optimizer gets
wrong, so it can do its usual excellent job of
On 02/10/2011 11:01 AM, Tom Lane wrote:
But I'm not interested in implementing Oracle-like hints just because
Oracle has them, which I think was basically what the OP wanted.
Hilariously, I'm not so sure that's what the OP wanted. Several of us
pointed him to EnterpriseDB and their
Shaun Thomas stho...@peak6.com wrote:
how difficult would it be to add that syntax to the JOIN
statement, for example?
Something like this syntax?:
JOIN WITH (correlation_factor=0.3)
Where 1.0 might mean that for each value on the left there was only
one distinct value on the right, and
Robert Haas robertmh...@gmail.com wrote:
maybe the FAQ should be rephrased to be more like we don't want
traditional hints because of problems X, Y, and Z. If you have
an idea that avoids those problems, let us know.
That's closer to where I think the community is on this issue
That
On 02/10/2011 11:21 AM, Kevin Grittner wrote:
Something like this syntax?:
JOIN WITH (correlation_factor=0.3)
I was thinking more:
JOIN foo_tab USING (foo_id) WITH (COST=50)
or something, to exploit the hooks that already exist for functions, for
example. But it's still an interesting
Shaun Thomas stho...@peak6.com wrote:
I was thinking more:
JOIN foo_tab USING (foo_id) WITH (COST=50)
The problem I have with that syntax is that it would be hard to read
when you have some nested set of joins or a (SELECT) in the JOIN
instead of simple table name. For me, at least, it
Shaun Thomas wrote:
Hilariously, I'm not so sure that's what the OP wanted.
Someone to blame as a scapegoat for why his badly planned project had
failed. I've done several Oracle conversions before, and never met
someone who was so resistent to doing the right things for such a
conversion.
robertmh...@gmail.com (Robert Haas) writes:
On Thu, Feb 10, 2011 at 11:45 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Well, I'm comfortable digging in my heels against doing *lame* hints
just because it's what all the other kids are doing, which I think
is the only thing which would
Greg Smith g...@2ndquadrant.com wrote:
Shaun Thomas wrote:
Hilariously, I'm not so sure that's what the OP wanted.
Someone to blame as a scapegoat for why his badly planned project
had failed. I've done several Oracle conversions before, and
never met someone who was so resistent to doing
On 2/10/11 9:21 AM, Kevin Grittner wrote:
Shaun Thomasstho...@peak6.com wrote:
how difficult would it be to add that syntax to the JOIN
statement, for example?
Something like this syntax?:
JOIN WITH (correlation_factor=0.3)
Where 1.0 might mean that for each value on the left there was
On 4 February 2011 04:46, Josh Berkus j...@agliodbs.com wrote:
Optimizer hints are used to work around problems in the optimizer and
introduce upgrade and maintenance issues. We would rather have the
problems reported and fixed. We have discussed a more sophisticated
system of per-class cost
Tobias Brox tobi...@gmail.com writes:
I have no clue about how hints works in Oracle ... I've never been
working enterprise level on anything else than Postgres. Anyway,
today I just came over an interesting problem in our production
database today - and I think it would be a benefit to be
http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want
No. 2 on the list.
Heck, *I* wrote that text.
I quote:
Optimizer hints are used to work around problems in the optimizer and
introduce upgrade and maintenance issues. We would rather have the
problems reported and fixed. We have
31 matches
Mail list logo
