| From: | Raimon Fernandez <coder(at)montx(dot)com> |
|---|---|
| To: | Vick Khera <vivek(at)khera(dot)org> |
| Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: SELECT is immediate but the UPDATE takes forever |
| Date: | 2010-12-09 16:08:41 |
| Message-ID: | 19459795-2782-415E-995F-9768EB144167@montx.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-interfaces |
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 "is the table bloated" was probably incorrect,
here you maybe are right
> and your answer to "is your I/O slow to grow a file" is also probably incorrect.
not sure as I'm not experiencing any slownes on the same machine with other postgresql databases that are also more or less the same size, I'm still a real newbie ...
thanks!
regards,
raimon
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gabi Julien | 2010-12-09 16:24:09 | Re: Postgresql 9.1 pg_last_xact_replay_timestamp limitations |
| Previous Message | tv | 2010-12-09 15:51:24 | Re: Tuning Postgres for single user manipulating large amounts of data |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Raimon Fernandez | 2010-12-09 16:26:27 | Re: use a variable name for an insert in a trigger for an audit |
| Previous Message | Vick Khera | 2010-12-09 13:32:51 | Re: SELECT is immediate but the UPDATE takes forever |