lts on analytics time with every
>>>>>> upgrade / tweak you do - starting with the upgrade to Pg 9.5.4
>>>>>>
>>>>>> Best regards
>>>>>> Calle
>>>>>>
>>>>>> On 19 October
index statistics (if the shape of your data has changed over
>>>>> time, this can make indices run faster).
>>>>>
>>>>>
>>>>>
>>>>> I’m new to PostgreSQL, but the core principles are the same, and a
>>>>> quick bit
gt;>>>
>>>>>> Like Brajesh, my background is MySQL, and one database admin task
>>>>>> that is often overlooked in MySQL is OPTIMIZE TABLEs. This reclaims
>>>>>> unused
>>>>>> space (we’ve had 10
19 October 2016 at 13:28, Sam Johnson <samuel.john...@qebo.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Neeraj,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Using VACUUM and ANAL
LEs. This reclaims
>>>>>> unused
>>>>>> space (we’ve had 100Gb databases files drop to half their size) and
>>>>>> refreshes index statistics (if the shape of your data has changed over
>>>>>> time, this can make indices run fas
;>>>> Like Brajesh, my background is MySQL, and one database admin task
>>>>>> that is often overlooked in MySQL is OPTIMIZE TABLEs. This reclaims
>>>>>> unused
>>>>>> space (we’ve had 100Gb databa
s run faster).
>>>>>
>>>>>
>>>>>
>>>>> I’m new to PostgreSQL, but the core principles are the same, and a
>>>>> quick bit of Googling shows that the equivalents in PostgreSQL are the
>>>>> VACUUM and ANALYZE co
ll literally rewrite all of
>>>> your database tables and indices into smaller, more efficient files (note,
>>>> however, that on a 500Gb database this could take a *looong* time –
>>>> perhaps test on a backup first?). The following forum post is a really
>&g
500Gb database this could take a *looong* time – perhaps test on a
>>> backup first?). The following forum post is a really nice, plain-English
>>> explanation of what VACUUM does:
>>>
>>> http://dba.stackexchange.com/questions/126258/what-is-table-
>>>
; bloating-in-databases
>>
>>
>>
>> As I mentioned, my background is MySQL rather than Postgres, so someone
>> with more specific Postgres experience might like to also chime in here.
>>
>>
>>
>> Cheers, Sam.
>>
>>
s-table-
>> bloating-in-databases
>>
>>
>>
>> As I mentioned, my background is MySQL rather than Postgres, so someone
>> with more specific Postgres experience might like to also chime in here.
>>
>>
>>
>> Cheers, Sam.
>>
>>
=qebo.co.uk@lists.
> launchpad.net> on behalf of Brajesh Murari <brajesh.mur...@gmail.com>
> *Date: *Wednesday, 19 October 2016 at 08:28
> *To: *Knut Staring <knu...@gmail.com>
> *Cc: *DHIS 2 Users list <dhis2-users@lists.launchpad.net>, DHIS2
> Developers <
<dhis2-users@lists.launchpad.net>, DHIS2 Developers
<dhis2-d...@lists.launchpad.net>
Subject: Re: [Dhis2-users] [Dhis2-devs] 25 hours in completing Analytic
Hi Neeraj,
Using VACUUM and ANALYZE
Like Brajesh, my background is MySQL, and one database admin task that is often
overlooked in
list <dhis2-users@lists.launchpad.net>, DHIS2 Developers
<dhis2-d...@lists.launchpad.net>
Subject: Re: [Dhis2-users] [Dhis2-devs] 25 hours in completing Analytic
Dear Neeraj,
The physical database size doesn't matter much, even the number of records
don't matter. In my experience the bigg
Dear Neeraj,
The physical database size doesn't matter much, even the number of records
don't matter. In my experience the biggest problem that one can going to
run in to is not size, but the number of queries you can handle at a time
instance specially during analytic functionality execution.
15 matches
Mail list logo
