Re: Creation of temporary tables on read-only standby servers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: Creation of temporary tables on read-only standby servers
Date: 2010-10-20 20:31:16
Message-ID: 3738.1287606676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Wed, Oct 20, 2010 at 8:37 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think it's pointless to speculate about whether we might have divvied
>> up the meta-information about tables differently if we'd foreseen
>> wanting to do this. It is what it is, and there is *way* too much code
>> depending on it, both inside the backend and in clients. Any
>> reimplementation of temp tables will still have to expose largely the
>> same catalog information that exists for tables now. We can probably
>> get away with marginal changes like redefining relfilenode, but we can't
>> avoid providing catalog entries that describe the schema and statistics
>> of a temp table.

> I agree about the schema -- that's the whole point of the catalog tables.

> I felt like the statistics were pretty marginal to begin with.

I'm thinking more of pg_statistic than the stuff in pg_class --- I agree
that we could probably kluge some other approach for relpages and
reltuples, but that doesn't scale to the real statistics.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-10-20 20:33:41 Re: max_wal_senders must die
Previous Message Robert Haas 2010-10-20 20:23:25 Re: WIP: extensible enums