On Thu, Feb 10, 2011 at 7:32 PM, Craig James wrote:
> On 2/10/11 9:21 AM, Kevin Grittner wrote:
>>
>> Shaun Thomas 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)
>>
>> W
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 :
> On Wed, Feb 16, 2011 at 4:22 PM, Bruce Momjian wrote:
>> I
On Wed, Feb 16, 2011 at 4:22 PM, Bruce Momjian 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
> a 1 .
Kevin Grittner wrote:
> Shaun Thomas 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 disti
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 02/11/2011 12:26 PM, Tobias Brox wrote:
2011/2/11 Vitalii Tymchyshyn:
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.
Concurrent
2011/2/11 Vitalii Tymchyshyn :
>> 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 add larg
11.02.11 11:29, Tobias Brox написав(ла):
2011/2/11 Віталій Тимчишин:
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 maintena
2011/2/11 Віталій Тимчишин :
> 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 (upgrading the index as
2011/2/10 Tobias Brox
> On 4 February 2011 04:46, Josh Berkus 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
> > syste
Tobias Brox 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 able to
> expl
On 4 February 2011 04:46, Josh Berkus 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 adjustment ins
On 2/10/11 9:21 AM, Kevin Grittner wrote:
Shaun Thomas 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 va
Greg Smith 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 the right thi
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.
Shaun Thomas 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 would "get lost"
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 conc
Robert Haas 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 sounds pretty g
Shaun Thomas 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 0.0 would mean t
On Thu, Feb 10, 2011 at 12:01 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Robert Haas 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
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 Oracle-sty
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 ev
On Thu, Feb 10, 2011 at 11:45 AM, Kevin Grittner
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 both on-list posts and
"Kevin Grittner" writes:
> Robert Haas 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 all the other kids are doing," which I
Robert Haas 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 equivalent constructs and
On Thu, Feb 3, 2011 at 8:46 PM, Josh Berkus 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 adjustme
> 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 ha
27 matches
Mail list logo
