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

Re: per-tablespace random_page_cost/seq_page_cost

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>,pgsql-hackers(at)postgresql(dot)org, Greg Stark <gsstark(at)mit(dot)edu>,Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: per-tablespace random_page_cost/seq_page_cost
Date: 2009-11-02 17:40:16
Message-ID: 20091102174016.GC4617@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas escribió:

> I don't see anything in this code that is very rel-specific, so I
> think it would be possible to implement spcoptions by just defining
> RELOPT_KIND_TABLESPACE and ignoring the irony, but that has enough of
> an unsavory feeling that I'm sure someone is going to complain about
> it...  I suppose we could go through and systematically rename all
> instances of reloptions to ent(ity)options or storageoptions or
> gen(eric)options or somesuch...

Maybe I missed part of the discussion, but do these really need to be
handled like reloptions instead of like datoptions?  Perhaps the
deciding factor is that we want to parse them once and store them in a
cache, so like reloptions; the others are used once per connection and
then thrown away.

If this is the case, then I think we could just decide that their name
is reloptions due to hysterical reasons and be done with it.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-11-02 17:42:04
Subject: Re: Some notes about Param handling with "Oracle style" plpgsql variables
Previous:From: Steve AtkinsDate: 2009-11-02 17:06:00
Subject: Re: Error on compile for Windows

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