On Mon, Apr 7, 2014 at 10:38:52AM -0400, Ryan Johnson wrote:
> The two * entries were produced by runs under SI, and confirm that
> the rest of the system has not been slowing down nearly as much as
> SSI. SI throughput dropped by 5% as the database quadrupled in size.
> SSI throughput dropped by
Dave,
Thanks for asking about the structure. I can say that it appears to me to
be fairly moderately structured, and I will list those aspects that I think
make it defined (STRUCTURED), and those which are more variable
(Moderately...).
STRUCTURED:
Location - Values are keyed according to a locat
I have this table that is quite big (several gig).
I was looking for a row manually (because a query would take too long)
- I know there is correlation between id and date, so I was doing
manual binary search for the id range that holds certain date, and I
found an interesting case where the plann
On Thu, Apr 3, 2014 at 09:01:08PM +0300, Heikki Linnakangas wrote:
> >Is there something I can set in the PGSQL parameters or in the file
> >system parameters to force a steady flow of writes to disk rather
> >than waiting for a sync system call? Mounting with "commit=1" did not
> >make a differenc
On Tue, Apr 8, 2014 at 02:00:05PM +, Shaun Thomas wrote:
> So if you are on a 1GB RAID card, set it to 1GB. Once you have 1GB
> of dirty memory (from a checkpoint or whatever), Linux will begin
> flushing.
>
> This is a pretty well-known issue on Linux systems with large amounts
> of RAM. Most
On Wed, Apr 2, 2014 at 11:38:57AM +0200, Alexey Klyukin wrote:
> In most cases 8GB should be enough even for the servers with hundreds of GB of
> data, since the FS uses the rest of the memory as a cache (make sure you give
> a
> hint to the planner on how much memory is left for this with the
>
