Tom Lane <[EMAIL PROTECTED]> wrote:
> "ITAGAKI Takahiro" <[EMAIL PROTECTED]> writes:
> > All of filler fields in branches, tellers and history is NULL. It is
> > probabbly a mistake because there are fields of char(22-88) in the table
> > definitions.
> > TPC-B requires at least 100 bytes per row
Actually, the reason for utilizing all available RAM is to improve
efficiency. There is no cost to leaving things in core, in case they
will can be re-used. It takes virtually no time to make pages
available when they are needed. The only cost is in managing
utilization maps, but accessi
Thank you for the explanations.
My program is running 4 months, it has never exit because of the shortage of
memory. But the 'free' memory (observing by top command) is kept on about
20MB (The database server has 2GB DDR RAM).
According to you explanations, when I "malloc" a buffer of 30MB, the
>>> On Wed, Oct 17, 2007 at 2:49 AM, in message
<[EMAIL PROTECTED]>, "ssurui"
<[EMAIL PROTECTED]> wrote:
> After long time, the free memory is
> not increased, it still 300M memory vanished
I think the one thing everyone knows as a fact is that the memory did
not vanish. Your latest message
"ITAGAKI Takahiro" <[EMAIL PROTECTED]> writes:
> All of filler fields in branches, tellers and history is NULL. It is
> probabbly a mistake because there are fields of char(22-88) in the table
> definitions.
> TPC-B requires at least 100 bytes per row for all tables used in it.
I'm not in favor of
The following bug has been logged online:
Bug reference: 3681
Logged by: ITAGAKI Takahiro
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.5, 8.3beta1
Operating system: independent
Description:fillers are NULL in pgbench
Details:
All of filler fields in bran
Today I examine this case in Oracle database by Oracle client tools
executing same SQL.
After 2 minutes, the SQL is executed over, 300M memory is vanished. But
after 5 minutes, the free memory is increased to the original level (I also
use top command of Linux).
Same experiments I done for Postgres
