Re: [PERFORM] Unblock tables

2011-02-11 Thread Scott Marlowe
On Fri, Feb 11, 2011 at 11:35 AM, Cesar Arrieta wrote: > Hi, I wanted to know, if there is some configuration in order tables dont > get blocked for too long time? Blocked by what? And how exactly are they blocked? What's a long time? I think we need more explanation of the problem before we c

Re: [PERFORM] Why we don't want hints Was: Slow count(*) again...

2011-02-11 Thread Pierre C
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

[PERFORM] Unblock tables

2011-02-11 Thread Cesar Arrieta
Hi, I wanted to know, if there is some configuration in order tables dont get blocked for too long time?

Re: [PERFORM] High load,

2011-02-11 Thread Jignesh Shah
On Thu, Jan 27, 2011 at 6:36 AM, Michael Kohl wrote: > Cédric, thanks a lot for your answer so far! > > On Thu, Jan 27, 2011 at 12:24 PM, Cédric Villemain > wrote: > >> you have swap used, IO on the swap partition ? > > Memory-wise we are fine. > >> can you paste the /proc/meminfo ? > > Sure: > >

Re: [PERFORM] Re: Indexes with condition using immutable functions applied to column not used

2011-02-11 Thread Nick Lello
Should there be a Rule for Select to cause partitions to be excluded ? On 8 February 2011 20:08, Sylvain Rabot wrote: > I also tried to do table partitioning using the same immutable function, > it works well except for constraint exclusion. > > CREATE TABLE mike.directory_part_0 () INHERITS (m

Re: [PERFORM] Why we don't want hints Was: Slow count(*) again...

2011-02-11 Thread Andrea Suisani
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

Re: [PERFORM] Why we don't want hints Was: Slow count(*) again...

2011-02-11 Thread Tobias Brox
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

Re: [PERFORM] Why we don't want hints Was: Slow count(*) again...

2011-02-11 Thread Vitalii Tymchyshyn
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

Re: [PERFORM] Why we don't want hints Was: Slow count(*) again...

2011-02-11 Thread 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 maintenance head-ache (upgrading the index as

Re: [PERFORM] Why we don't want hints Was: Slow count(*) again...

2011-02-11 Thread Віталій Тимчишин
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