Christopher Kings-Lynne wrote:
True, that does seem unusual.

--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

I'll do it.

Chris


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Christopher Kings-Lynne <chriskl (AT) familyhealth (DOT) com.au> writes:
I had forgotten that the original patch allowed that. Personally I'd
vote for taking it out, for the above-stated reasons --- any objections?

If people do want to have it then we can instead change ALTER SET
TABLESPACE to allow sequences; but we'd also need a nontrivial addition
to pg_dump, so there had better be a better reason than "might be nice
to have".

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

Will toast go in the same tablespace as the base table? I can see some
advantages to splitting that to another drive for extreme cases (think
heap/toast lookups over and over again).

---------------------------------------------------------------------------

Tom Lane wrote:
--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

However, based on our feature freeze, maybe what we have now is fine and
I can just add the TODO item again.

---------------------------------------------------------------------------

Tom Lane wrote:
--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

I vote for taking it out.

Chris

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

On Mon, 12 Jul 2004, Christopher Kings-Lynne wrote:

Pull it. I added it intentionally but now I'm questioning my reasoning
(which was, sequences might be accessed lots, people might want to put
them somewhere intentionally).

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Bruce Momjian <pgman (AT) candle (DOT) pha.pa.us> writes:
That is the current design, and I'd prefer to keep it that way because
anything else adds great complexity for unclear gain.

Two examples of pain points:

1. That pending patch to report a table's tablespace in psql \d would
get lots more complex: you'd have up to three tablespaces to worry about
(base table, toast table, toast index).

2. How would pg_dump restore such a setup? It could not generate a
script that says ALTER TABLE pg_toast.pg_toast_NNN SET TABLESPACE,
because it has no way to know what NNN should be. I think we'd have
to add locutions like "ALTER TABLE foo SET TOAST TABLESPACE t" and
"ALTER TABLE foo SET TOAST INDEX TABLESPACE t" to do this in a clean
fashion.

In fact, now that I think of it, the patch-as-committed already
introduces some serious headaches for pg_dump: it can't know for sure
what name will be assigned to constraint indexes (pkey and unique
indexes) so it has no good way to emit ALTER TABLE SET TABLESPACE
commands for those indexes.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

Gavin Sherry <swm (AT) linuxworld (DOT) com.au> writes:
I thought about that, but AFAICS a heavily used sequence would merely
end up as a single hot entry in the shared buffer arena (or at worst,
an often-hit page in kernel buffers). It could not result in a lot of
actual I/O because it's only one page; at most one would expect one
write per checkpoint cycle. So putting it on particularly fast disk
would be a useless exercise.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

I guess I'll have to make it punt that the name will be what it
currently is

Otherwise, we need to extend the ADD CONSTRAINT syntax. That would be
handy because the you could specify the TABLESPACE at creation time as well.

Chris


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster