| From: | Mike Mascari <mascarm(at)mascari(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Temp tables and LRU-K caching |
| Date: | 2002-09-23 15:57:14 |
| Message-ID: | 3D8F39DA.4070802@mascari.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello.
I'm just curious as to the 7.3 status of a couple of things:
1. Back in Feb. I wrote (in regards to Oracle behavior):
"Unlike normal queries where blocks are added to the MRU end of
an LRU list, full table scans add the blocks to the LRU end of
the LRU list. I was wondering, in the light of the discussion of
using LRU-K, if PostgreSQL does, or if anyone has tried, this
technique?"
Bruce wrote:
"Yes, someone from India has a project to test LRU-K and MRU for
large table scans and report back the results. He will
implement whichever is best."
Did this make it into 7.3?
2. Gavin Sherry had worked up a patch so that temporary
relations could be dropped automatically upon transaction
commit. Did any of those patches it make it? I notice that
whenever I create a temporary table in a transaction, my HD
light blinks. Is this a forced fsync() causes by the fact that
the SQL standard defines temporary relations as surviving across
transactions? If so, I'd bet those of us who use
transaction-local temporary tables could get few drops more of
performance from an ON COMMIT drop patch w/o fsync.
Any thoughts?
Mike Mascari
mascarm(at)mascari(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paesold | 2002-09-23 16:03:54 | Getting current transaction id |
| Previous Message | Jean-Luc Lachance | 2002-09-23 15:47:01 | Re: Getting acces to MVCC version number |