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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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