On Thu, Jan 3, 2013 at 4:54 PM, Alex Vinnik wrote:
> Don't understand why PG doesn't use views_visit_id_index in that query but
> rather scans whole table. One explanation I have found that when resulting
> dataset constitutes ~15% of total number of rows in the table then seq scan
> is used. In t
On Mon, Jan 7, 2013 at 1:49 PM, james wrote:
> Is there a way to force a WAL flush so that async commits (from other
> connections) are flushed, short of actually updating a sacrificial row?
>
> Would be nice to do it without generating anything extra, even if it is
> something that causes IO in t
Le 2013-01-07 à 16:49, james a écrit :
Is there a way to force a WAL flush so that async commits (from other
connections) are flushed, short of actually updating a sacrificial row?
Would be nice to do it without generating anything extra, even if it is
something that causes IO in the checkpoi
Le 2013-01-07 à 16:49, james a écrit :
> Is there a way to force a WAL flush so that async commits (from other
> connections) are flushed, short of actually updating a sacrificial row?
>
> Would be nice to do it without generating anything extra, even if it is
> something that causes IO in the
Is there a way to force a WAL flush so that async commits (from other
connections) are flushed, short of actually updating a sacrificial row?
Would be nice to do it without generating anything extra, even if it is
something that causes IO in the checkpoint.
Am I right to think that an empty t
On Wed, Jan 2, 2013 at 3:46 PM, Shaun Thomas wrote:
> Hey everyone!
>
> After much testing and hair-pulling, we've confirmed two kernel settings
> that should always be modified in production Linux systems. Especially new
> ones with the completely fair scheduler (CFS) as opposed to the O(1)
> sch
Hi Patrick,
You really need a flash ZIL with ZFS to handle syncs effectively. Setting
the sync_commit to off is the best you can do without it. Not that that
is bad, we do that here as well.
Regards,
Ken
On Tue, Jan 08, 2013 at 01:18:02AM +0800, Patrick Dung wrote:
> Hi,
>
> Updated information
Fixed by
synchronous_commit = off
Суббота, 5 января 2013, 12:53 +04:00 от nobody nowhere :
> > > [ all postgres processes seem to be pinned to CPU 14 ]
> >
> > I wonder whether this is a "benefit" of sched_autogroup_enabled?
> >
> > http://archives.postgresql.org/message-id/50e4aab1.9040...@
Hi,
Updated information in this post.
I have installed Postgresql 9.2.2 (complied by gcc) in FreeBSD 9.1 i386.
The pgsql base directory is in a ZFS dataset.
I
have noticed the performance is sub-optimal, but I know the default
setting should be the most safest one to be use (without possible d
