From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: unlogged tables vs. GIST |
Date: | 2013-01-15 18:10:05 |
Message-ID: | 50F59B7D.1010109@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15.01.2013 08:54, Jeevan Chalke wrote:
> For (2), I have added a new function called, GetXLogRecPtrForUnloogedRel()
> which returns a fake LSN for GiST indexes. However, I have removed
> GetXLogRecPtrForTemp() function and added its functionality inside this new
> function itself to avoid complexity.
I don't much care for using a new field in the control file for this.
First, it seems like a big modularity violation to store a gist-specific
counter in the control file. Second, you'd be generating a lot of
traffic on the ControlFileLock. It's not heavily contended at the
moment, but when the control file is updated, it's held over an fsync,
which could cause unnecessary stalls to insertions to unlogged gist
tables. And it's just a bad idea to share a lock for two things with
completely different characteristics in general.
Could we stash the counter e.g. in the root page of the index?
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-01-15 18:16:44 | Re: logical changeset generation v4 |
Previous Message | Stephen Frost | 2013-01-15 17:31:17 | Re: [PATCH] COPY .. COMPRESSED |