Skip site navigation (1) Skip section navigation (2)

Re: unlogged tables vs. GIST

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: (view raw, whole thread or download thread mbox)
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
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2013-01-15 18:44:37
Subject: Re: unlogged tables vs. GIST
Previous:From: Andres FreundDate: 2013-01-15 18:30:35
Subject: Re: logical changeset generation v4

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group