On 9dic, 2010, at 14:32 , Vick Khera wrote:
>> well, after a VACUUM things are going faster ... I'm still trying to analyze
>> the function as it seems there are other bottlechecnk, but at least the
>> first update now is faster as before ...
>>
>
> If that's the case then your 'no' answer to
On Wed, Dec 8, 2010 at 10:58 PM, Raimon Fernandez wrote:
> well, after a VACUUM things are going faster ... I'm still trying to analyze
> the function as it seems there are other bottlechecnk, but at least the first
> update now is faster as before ...
>
If that's the case then your 'no' answer
On 7dic, 2010, at 16:37 , Tom Lane wrote:
>> Quoting Raimon Fernandez :
>>> I want to understand why one of my postgresql functions takes an
>>> eternity to finish.
>
>> Maybe there is any check or constraint on belongs_to_compte_id.comptes that
>> might take longer?
>
> Or maybe the UPDATE is
On 8dic, 2010, at 18:18 , Vick Khera wrote:
> 2010/12/7 Raimon Fernandez :
>> I'm using now another database with same structure and data and the delay
>> doesn't exist there, there must be something wrong in my current development
>> database.
>>
>
> does autovacuum run on it?
no
> is the
2010/12/7 Raimon Fernandez :
> I'm using now another database with same structure and data and the delay
> doesn't exist there, there must be something wrong in my current development
> database.
>
does autovacuum run on it? is the table massively bloated? is your
disk system really, really slo
On 7dic, 2010, at 15:45 , Michał Roszka wrote:
> Quoting Raimon Fernandez :
>
>> I want to understand why one of my postgresql functions takes an
>> eternity to finish.
>>
>> Here's an example:
>>
>> UPDATE comptes SET belongs_to_compte_id=42009 WHERE (codi_compte LIKE
>> '1%' AND empresa_
=?utf-8?b?TWljaGHFgg==?= Roszka writes:
> Quoting Raimon Fernandez :
>> I want to understand why one of my postgresql functions takes an
>> eternity to finish.
> Maybe there is any check or constraint on belongs_to_compte_id.comptes that
> might take longer?
Or maybe the UPDATE is blocked on a l
On 7 Dec 2010, at 15:45, Michał Roszka wrote:
>> but the same SELECT count, it's immediate:
>>
>> SELECT count(id) FROM comptes WHERE codi_compte LIKE '1%' AND
>> empresa_id=2 AND nivell=11;
>
> Maybe there is any check or constraint on belongs_to_compte_id.comptes that
> might take longer?
Quoting Raimon Fernandez :
I want to understand why one of my postgresql functions takes an
eternity to finish.
Here's an example:
UPDATE comptes SET belongs_to_compte_id=42009 WHERE (codi_compte LIKE
'1%' AND empresa_id=2 AND nivell=11); // takes forever to finish
[...]
but the same S
Hi,
I want to understand why one of my postgresql functions takes an eternity to
finish.
Here's an example:
UPDATE comptes SET belongs_to_compte_id=42009 WHERE (codi_compte LIKE '1%'
AND empresa_id=2 AND nivell=11); // takes forever to finish
QUERY PLAN
10 matches
Mail list logo
