On Fri, Aug 10, 2012 at 3:15 PM, Strahinja Kustudić
wrote:
>
> For example, yesterday when I checked the database size on the production
> server it was 30GB, and the restored dump of that database was only 17GB.
> The most interesting thing is that the data wasn't bloated that much, but
> the ind
Christophe Pettus writes:
> Thanks, that makes sense. Something a colleague of mine just noticed is that
> the estimate cost of the Index Scan node isn't being included in the cost of
> the Merge Join above it, which makes the Merge Join seem much cheaper than it
> really is. Could this be a
On Aug 13, 2012, at 6:35 PM, Tomas Vondra wrote:
> On 14 Srpen 2012, 3:15, Christophe Pettus wrote:
>> Consider this EXPLAIN ANALYZE output:
>>
>> http://explain.depesz.com/s/TCi
>>
>> Note the Bitmap Heap Scan at the bottom claims to be producing 7094 rows,
>> and the Sort above it expect
On 14 Srpen 2012, 3:15, Christophe Pettus wrote:
> Consider this EXPLAIN ANALYZE output:
>
> http://explain.depesz.com/s/TCi
>
> Note the Bitmap Heap Scan at the bottom claims to be producing 7094 rows,
> and the Sort above it expects to be processing 7330 rows (the same number
> the Bitmap H
Consider this EXPLAIN ANALYZE output:
http://explain.depesz.com/s/TCi
Note the Bitmap Heap Scan at the bottom claims to be producing 7094 rows, and
the Sort above it expects to be processing 7330 rows (the same number the
Bitmap Heap Scan expected to produce)... but the sort is actually
> Any ideas on any of this? Why the sawteeth? Why the rise-then-drop?
Well, my first thought on the sawteeth is that you have archive_timeout
set to 15 minutes. No?
As for the gradual buildup over days, that most likely corresponds to
either changes in application activity levels, or some kind
On 11/08/12 10:15, Strahinja Kustudić wrote:
We have PostgreSQL 9.1 running on Centos 5 on two SSDs, one for indices and
one for data. The database is extremely active with reads and writes. We
have autovacuum enabled, but we didn't tweak it's aggressiveness. The
problem is that after some time t
On Sun, Aug 12, 2012 at 7:17 PM, David Barton wrote:
>>
>> A relatively easy change would be to make any given autovacuum worker
>> on start up tolerate a stats file that is out of date by up to, say,
>> naptime/5. That would greatly reduce the amount of writing the stats
>> collector needs to do
On Fri, Jul 20, 2012 at 4:27 AM, mark wrote:
> We have put some deferred constraints (some initially immediate, some
> initially deferred) into our database for testing with our applications.
> I understand a lot more may have to be tracked through a transaction and
> there could be some impact f
