From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(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:33:17 |
Message-ID: | CA+TgmoaKxYxLQaj21F3MVzAMfdm8G+JVabvJta6OVt2WnDyVRw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> 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?
That would require maintaining a counter per table rather than a
single global counter, which would be bad because then we'd need to
store one counter in shared memory for every table, rather than just
one, period, which runs up against the fixed sizing of shared memory.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-01-15 18:44:37 | Re: unlogged tables vs. GIST |
Previous Message | Andres Freund | 2013-01-15 18:30:35 | Re: logical changeset generation v4 |