Re: Hard to Use WAS: Hard limit on WAL space - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Hard to Use WAS: Hard limit on WAL space
Date
Msg-id CAM-w4HOU+ua=uR1cRZp5eNgJXT_g8NZe7121LMxU774ey0_PPQ@mail.gmail.com
Whole thread Raw
In response to Re: Hard to Use WAS: Hard limit on WAL space  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
> fsync=off

synchronous_commits=off replaced fsync=off in almost every use case
where fsync=off might have been useful. The only remaining use case is
for the initial build of a database. In that case what the user really
wants is to turn off WAL logging entirely though. Having a WAL log and
not fsyncing it is kind of pointless. I guess it lets you replicate
the database but it doesn't let you use the WAL log for recovery
locally.

> Bloat
> ------
>
> Table bloat. Table bloat has been a major issue with PostgreSQL users/admins
> for years. Anyone care to explain to me in a simple paragraph how to find
> out if you have table or index bloat issues in your database and what to do
> about it? (Maybe we need "pg_catalog.pg_index_bloat" and
> "pg_catalog.pg_table_bloat" views including FILLFACTOR correction?)

A nice view that exposes a summary of information from the fsm per
table would be pretty handy.

In general there's a lot of data tied up in things like the fsm that
could be usefully exposed to users.



-- 
greg



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: request a new feature in fuzzystrmatch
Next
From: Tom Lane
Date:
Subject: Postgres 9.3beta2 coming week after next