Moncure [mailto:mmonc...@gmail.com]
Sent: Wednesday, June 13, 2012 8:36 PM
To: Amit Kapila
Cc: PostgreSQL-development
Subject: Re: [HACKERS] hint bit i/o reduction
On Wed, Jun 13, 2012 at 9:02 AM, Amit Kapila amit.kap...@huawei.com wrote:
Yes, but only in the unhinted case -- in oltp workloads
bit for a already dirty page.
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Merlin Moncure
Sent: Wednesday, June 13, 2012 4:28 AM
To: PostgreSQL-development
Subject: [HACKERS] hint bit i/o reduction
hackers,
A while
On Wed, Jun 13, 2012 at 3:57 AM, Amit Kapila amit.kap...@huawei.com wrote:
1) Keep track # times the last transaction id was repeatedly seen in
tqual.c (resetting as soon as a new xid was touched. We can do this
just for xmin, or separately for both xmin and xmax.
Will this be done when we
: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: Wednesday, June 13, 2012 6:50 PM
To: Amit Kapila
Cc: PostgreSQL-development
Subject: Re: [HACKERS] hint bit i/o reduction
On Wed, Jun 13, 2012 at 3:57 AM, Amit Kapila amit.kap...@huawei.com wrote:
1) Keep track # times the last transaction id
On Wed, Jun 13, 2012 at 9:02 AM, Amit Kapila amit.kap...@huawei.com wrote:
Yes, but only in the unhinted case -- in oltp workloads tuples get
hinted fairly quickly so I doubt this would be a huge impact. Hinted
scans will work exactly as they do now. In the unhinted case for OLTP
a few
hackers,
A while back I made an effort implementing a backend local hint bit
cache with the intention of mitigating i/o impact for scan heavy
workloads that involve moving a lot of records around per transaction.
The basic concept was to keep some backend private memory that
tracked the
