Tom Lane wrote:
> Bruce Momjian writes:
> > Greg Stark wrote:
> >> It seems to me simpler and more direct to just nail relcache
> >> entries for these objects into memory and manipulate them directly.
> >> They can be constructed from the global catalog tables and then
> >> tweaked to point to the
On Oct 19, 2010, at 2:01 PM, Martijn van Oosterhout wrote:
> On Tue, Oct 19, 2010 at 02:52:01PM -0400, Robert Haas wrote:
>> Well, temp tables really want a separate set of XIDs with a separate
>> CLOG, too. Admittedly, they don't necessarily need WAL, if you can
>> make them work without catalog
On Thu, Oct 21, 2010 at 7:13 PM, Tom Lane wrote:
> ... and as I recall, we got rid of it principally because the temp
> tables weren't visible to ordinary catalog lookups, thus breaking
> all sorts of client-side logic.
>
Though that wouldn't be the case if the catalogs held a template.
Anyw
Bruce Momjian writes:
> Greg Stark wrote:
>> It seems to me simpler and more direct to just nail relcache
>> entries for these objects into memory and manipulate them directly.
>> They can be constructed from the global catalog tables and then
>> tweaked to point to the backend local temporary tab
Tom Lane wrote:
> Bruce Momjian writes:
> > Currently it isn't possible to create temporary tables on read-only
> > standby servers, and I don't see it listed on the TODO list. Can I add
> > it?
>
> Not unless you have some credible concept for how it might ever be
> implemented. You can't crea
Greg Stark wrote:
> On Tue, Oct 19, 2010 at 12:03 PM, Robert Haas wrote:
> > The trick is that it would require us to have two pg_class tables, two
> > pg_attribute tables, two pg_attrdef tables, etc.: in each case, one
> > permanent and one temporary. ?I am not sure how complex that will turn
> >
Greg Stark writes:
> On Wed, Oct 20, 2010 at 8:37 AM, Tom Lane 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
>> depen
On Wed, Oct 20, 2010 at 8:37 AM, Tom Lane 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 th
Greg Stark writes:
> On Tue, Oct 19, 2010 at 4:12 PM, Tom Lane wrote:
>> I think they're more alike than you think. If we had the infrastructure
>> to do local temp tables this way, it'd be pretty easy to use that to
>> instantiate per-backend copies of global temp tables. (The global
>> entiti
On Tue, Oct 19, 2010 at 4:12 PM, Tom Lane wrote:
> ... and relpages and reltuples ...
Those are hardly very convincing examples. Neither are values that
need to be updated in transactions and neither relates to the
definition of the table. They could be moved from pg_class to some
internal data s
Greg Stark writes:
> On Tue, Oct 19, 2010 at 3:45 PM, Tom Lane wrote:
>> Relcache entries alone are not gonna work. There is way too much stuff
>> that assumes that tables are correctly represented in the system
>> catalogs.
> Well we're talking about multiple things now. In the global temporar
On Tue, Oct 19, 2010 at 3:45 PM, Tom Lane wrote:
> Relcache entries alone are not gonna work. There is way too much stuff
> that assumes that tables are correctly represented in the system
> catalogs.
>
Well we're talking about multiple things now. In the global temporary
table case they *are* p
Greg Stark writes:
> On Tue, Oct 19, 2010 at 12:03 PM, Robert Haas wrote:
>> The trick is that it would require us to have two pg_class tables, two
>> pg_attribute tables, two pg_attrdef tables, etc.: in each case, one
>> permanent and one temporary. I am not sure how complex that will turn
>> o
2010/10/19 Greg Stark :
> On Tue, Oct 19, 2010 at 12:03 PM, Robert Haas wrote:
>> The trick is that it would require us to have two pg_class tables, two
>> pg_attribute tables, two pg_attrdef tables, etc.: in each case, one
>> permanent and one temporary. I am not sure how complex that will turn
On Tue, Oct 19, 2010 at 12:03 PM, Robert Haas wrote:
> The trick is that it would require us to have two pg_class tables, two
> pg_attribute tables, two pg_attrdef tables, etc.: in each case, one
> permanent and one temporary. I am not sure how complex that will turn
> out to be.
Tom suggested u
On Tue, Oct 19, 2010 at 3:01 PM, Martijn van Oosterhout
wrote:
> On Tue, Oct 19, 2010 at 02:52:01PM -0400, Robert Haas wrote:
>> Well, temp tables really want a separate set of XIDs with a separate
>> CLOG, too. Admittedly, they don't necessarily need WAL, if you can
>> make them work without cat
On Tue, Oct 19, 2010 at 02:52:01PM -0400, Robert Haas wrote:
> Well, temp tables really want a separate set of XIDs with a separate
> CLOG, too. Admittedly, they don't necessarily need WAL, if you can
> make them work without catalog entries, but that's not so easy either.
At one point there was
On Mon, Oct 18, 2010 at 6:05 PM, Greg Stark wrote:
> On Mon, Oct 18, 2010 at 1:27 PM, Robert Haas wrote:
>>> It'd be kinda cool if we had it, but the work required to get there
>>> seems far out of proportion to the benefits ...
>>
>> I agree. I think that's backing into the problem from the wro
On Mon, Oct 18, 2010 at 1:27 PM, Robert Haas wrote:
>> It'd be kinda cool if we had it, but the work required to get there
>> seems far out of proportion to the benefits ...
>
> I agree. I think that's backing into the problem from the wrong end.
> The limiting factor here is that we require the
On Mon, Oct 18, 2010 at 3:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane wrote:
>>> Andres Freund writes:
Hm. Wouldnt it be possible to use virtual xids for that purpose? They are
never seen outside of that session anyway...
>>>
>>> Well, may
Robert Haas writes:
> On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane wrote:
>> Andres Freund writes:
>>> Hm. Wouldnt it be possible to use virtual xids for that purpose? They are
>>> never seen outside of that session anyway...
>>
>> Well, maybe, but then you need infrastructure to track whether VXI
On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane wrote:
> Andres Freund writes:
>> On Monday 18 October 2010 20:06:01 Tom Lane wrote:
>>> Not unless you have some credible concept for how it might ever be
>>> implemented. You can't create temp tables because you can't modify
>>> system catalogs, and if
Andres Freund writes:
> On Monday 18 October 2010 20:06:01 Tom Lane wrote:
>> Not unless you have some credible concept for how it might ever be
>> implemented. You can't create temp tables because you can't modify
>> system catalogs, and if you did somehow create them you couldn't put
>> anythin
On Monday 18 October 2010 20:06:01 Tom Lane wrote:
> Bruce Momjian writes:
> > Currently it isn't possible to create temporary tables on read-only
> > standby servers, and I don't see it listed on the TODO list. Can I add
> > it?
>
> Not unless you have some credible concept for how it might eve
Bruce Momjian writes:
> Currently it isn't possible to create temporary tables on read-only
> standby servers, and I don't see it listed on the TODO list. Can I add
> it?
Not unless you have some credible concept for how it might ever be
implemented. You can't create temp tables because you can
2010/10/18 Bruce Momjian :
> Currently it isn't possible to create temporary tables on read-only
> standby servers, and I don't see it listed on the TODO list. Can I add
> it?
Yes, still probably something we partially visit with global temp
table thread from Robert Haas...
Having non-WALed glob
Currently it isn't possible to create temporary tables on read-only
standby servers, and I don't see it listed on the TODO list. Can I add
it?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to b
27 matches
Mail list logo
