Re: patch - per-tablespace random_page_cost/seq_page_cost

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: patch - per-tablespace random_page_cost/seq_page_cost
Date: 2010-01-04 18:44:11
Message-ID: 603c8f071001041044o4dcc4718gb6d03db9871af02e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 4, 2010 at 1:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Hmm, I see this needs to be rebased over Tom's latest changes, but the
>> conflict I got was in syscache.h, rather than syscache.c.  Not sure if
>> that's what you were going for or if there's another issue.  Updated
>> patch attached.
>
> I'm planning to go look at Naylor's bki refactoring patch now.  Assuming
> there isn't any showstopper problem with that, do you object to it
> getting committed first?  Either order is going to create a merge
> problem, but it seems like we'd be best off to get Naylor's patch in
> so people can resync affected patches before the January commitfest
> starts.

My only objection to that is that if we're going to add attoptions
also, I'd like to get this committed first before I start working on
that, and we're running short on time. If you can commit his patch in
the next day or two, then I am fine with rebasing mine afterwards, but
if it needs more work than that then I would prefer to commit mine so
I can move on. Is that reasonable?

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-04 18:47:14 Re: Thoughts on statistics for continuously advancing columns
Previous Message Boszormenyi Zoltan 2010-01-04 18:39:14 ECPG SQLDA support