Re: unlogged tables vs. GIST

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: unlogged tables vs. GIST
Дата
Msg-id 50F5A6B8.8080105@vmware.com
обсуждение исходный текст
Ответ на Re: unlogged tables vs. GIST  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: unlogged tables vs. GIST  (Andres Freund <andres@2ndquadrant.com>)
Re: unlogged tables vs. GIST  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 15.01.2013 20:48, Tom Lane wrote:
> Robert Haas<robertmhaas@gmail.com>  writes:
>> On Tue, Jan 15, 2013 at 1:10 PM, Heikki Linnakangas
>> <hlinnakangas@vmware.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.

Not every insert, just every split. Which might still be a performance 
problem, but an order of magnitude smaller.

> I think a bigger issue is where we'd find any space for it.  There's no
> easily-spare space in a GIST page.

We could use a larger opaque struct, with the additional field, for the 
root page, for new indexes. As long as we continue to support the 
current layout too, that won't break on-disk compatibility. We didn't 
support unlogged gist indexes before, so we won't have to worry about 
upgrading unlogged indexes that miss the field.

Or if 32 bits is enough for this, we could reuse the right-link. The 
root page has no right link, so it can be repurposed.

> 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.

Yeah.

> 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
> XLOG LSNs?

One thought I had is that we only generate an NSN when a page is split, 
and gist never deletes pages, so how about simply using the block number 
of the newly split page as the NSN? That closes the chance of 
reinventing page recycling in the future, though.

- Heikki



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_retainxlog for inclusion in 9.3?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Curious buildfarm failures (fwd)