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

Re: per-tablespace random_page_cost/seq_page_cost

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: David Fetter <david(at)fetter(dot)org>, 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-10-28 02:18:03
Message-ID: 25799.1256696283@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> For things like autovacuum options, the actual representation probably
> doesn't matter much because I'm guessing that the amount of work being
> done by vacuum dwarfs the parsing cost, and it's a background task
> anyway.  But this seems like a less solid argument for things like
> fillfactor and the proposed per-tablespace
> seq_page_cost/random_page_cost, which will be accessed by many queries
> and in the latter case often more than once.  Ideally (or so it seems
> to me) you'd like to fetch those things out of Form_pg_whatever rather
> than parsing text strings to get at 'em.

I think efficiency arguments here are hogwash.  In the first place,
we'd certainly cache the results someplace (relcache or something like
it) if retrieve performance seems to be a bottleneck at all.  In the
second place, composite types are so hugely inefficient as to swamp any
gain you'd get from the columns being the right type once you got at
them.  (atoi and friends are cheap by comparison.)

It's possible that changing this is worthwhile on logical cleanliness
grounds; but I think it will be a net loss in efficiency, and definitely
a net loss in terms of code complexity at the C level.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Itagaki TakahiroDate: 2009-10-28 02:27:35
Subject: pg_read_file() and non-ascii input file
Previous:From: Robert HaasDate: 2009-10-28 02:10:46
Subject: Re: per-tablespace random_page_cost/seq_page_cost

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