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

Re: unlogged tables vs. GIST

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: unlogged tables vs. GIST
Date: 2013-01-15 18:53:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jan 15, 2013 at 1:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)com> wrote:
>>> 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.
> I think what Heikki had in mind was that the copy in the index would be
> the authoritative one, not some image in shared memory.  This'd imply
> dirtying the root page on every insert, as well as increased contention
> for the root page, so it might have performance problems.
> I think a bigger issue is where we'd find any space for it.  There's no
> easily-spare space in a GIST page.  This reminds me again that the lack
> of a metapage in GIST was a serious design error, which we should
> correct if we ever break on-disk compatibility again.
> I concur that adding such a counter to pg_control is a nonstarter,
> though.
> Given that we don't need crash recovery for an unlogged table, could
> we get away with some variant of NSN that has weaker semantics than

It needs to be strictly ascending and survive clean shutdowns.  Is
there some place we could preserve it other than the control file?

I was assuming we wanted a single sequence shared across all relations
rather than a sequence per relation, but I don't know of any reason
why that's actually required.

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2013-01-15 18:54:33
Subject: Re: pg_retainxlog for inclusion in 9.3?
Previous:From: Robert HaasDate: 2013-01-15 18:51:00
Subject: Re: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

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