Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Note that it introduces a LEFT JOIN on pg_class to itself that's always present, even for server versions that do not support reloptions. Personally I'd be more worried about the unnest(). Also, please schema-qualify that function name; you can't assume anything about the search path here. Maybe it would be more elegant to put the search_path into proconfig? This would have some advantages: 0. Looks less weird. 1. We could quasi-automatically verify that all SQL-language functions have the correct search path (or even set it in initdb). 2. On things like unnest, which is a language element that we happen to implement as a function now, you don't have to worry about it one way or the other. In a shell script, you'd usually set the path at the top instead of writing out the directories of every command. It looks better (reason 0), it's easier to analyze (e.g., lintian) (reason 1), and it avoids confusion with shell built-ins (reason 2). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Peter Eisentraut pete...@gmx.net writes: Tom Lane wrote: Personally I'd be more worried about the unnest(). Also, please schema-qualify that function name; you can't assume anything about the search path here. Maybe it would be more elegant to put the search_path into proconfig? This is psql's describe.c, not a sql function. It hasn't got a proconfig, and it doesn't seem like a particularly good idea to make it try to replace the user's search path setting directly. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Note that it introduces a LEFT JOIN on pg_class to itself that's always
present, even for server versions that do not support reloptions.
Personally I'd be more worried about the unnest(). Also, please
schema-qualify that function name; you can't assume anything about
the search path here.
This version should fix these issues. I refrained from adding more ? :
expressions because it starts getting ugly for my taste.
Index: src/bin/psql/describe.c
===
RCS file: /home/alvherre/cvs/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.198
diff -c -p -r1.198 describe.c
*** src/bin/psql/describe.c 22 Jan 2009 20:16:08 - 1.198
--- src/bin/psql/describe.c 11 Feb 2009 01:19:11 -
***
*** 8,14
*
* Copyright (c) 2000-2009, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/describe.c,v 1.198 2009-01-22 20:16:08 tgl Exp $
*/
#include postgres_fe.h
--- 8,14
*
* Copyright (c) 2000-2009, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/describe.c,v 1.197 2009/01/20 02:13:42 momjian Exp $
*/
#include postgres_fe.h
*** describeOneTableDetails(const char *sche
*** 871,876
--- 871,877
bool verbose)
{
PQExpBufferData buf;
+ PQExpBufferData reloptbuf;
PGresult *res = NULL;
printTableOpt myopt = pset.popt.topt;
printTableContent cont;
*** describeOneTableDetails(const char *sche
*** 908,923
initPQExpBuffer(title);
initPQExpBuffer(tmpbuf);
/* Get general table info */
printfPQExpBuffer(buf,
! SELECT relchecks, relkind, relhasindex, relhasrules, %s,
! relhasoids
! %s%s\n
! FROM pg_catalog.pg_class WHERE oid = '%s',
! (pset.sversion = 80400 ? relhastriggers : reltriggers 0),
! (pset.sversion = 80200 verbose ?
! , pg_catalog.array_to_string(reloptions, E', ') : ,''),
! (pset.sversion = 8 ? , reltablespace : ),
oid);
res = PSQLexec(buf.data, false);
if (!res)
--- 909,944
initPQExpBuffer(title);
initPQExpBuffer(tmpbuf);
+ if (verbose)
+ {
+ initPQExpBuffer(reloptbuf);
+ if (pset.sversion = 80400)
+ {
+ printfPQExpBuffer(reloptbuf,
+ pg_catalog.array_to_string(c.reloptions ||
+ array(select 'toast.' || x from pg_catalog.unnest(tc.reloptions) x), ', ')\n);
+ }
+ else if (pset.sversion = 80200)
+ {
+ printfPQExpBuffer(reloptbuf,
+ pg_catalog.array_to_string(c.reloptions, ', ')\n);
+ }
+ else
+ printfPQExpBuffer(reloptbuf, ''\n);
+ }
+
+
/* Get general table info */
printfPQExpBuffer(buf,
! SELECT c.relchecks, c.relkind, c.relhasindex, c.relhasrules, %s,
! c.relhasoids,
! %s%s\n
! FROM pg_catalog.pg_class c\n
! LEFT JOIN pg_catalog.pg_class tc ON (c.reltoastrelid = tc.oid)\n
! WHERE c.oid = '%s'\n,
! (pset.sversion = 80400 ? c.relhastriggers : c.reltriggers 0),
! verbose ? reloptbuf.data : '',
! (pset.sversion = 8 ? , c.reltablespace : ),
oid);
res = PSQLexec(buf.data, false);
if (!res)
*** error_return:
*** 1672,1677
--- 1693,1700
termPQExpBuffer(buf);
termPQExpBuffer(title);
termPQExpBuffer(tmpbuf);
+ if (verbose)
+ termPQExpBuffer(reloptbuf);
if (seq_values)
{
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Alvaro Herrera alvhe...@commandprompt.com writes: This version should fix these issues. I refrained from adding more ? : expressions because it starts getting ugly for my taste. I think you might as well just introduce two separate code paths to produce the 8.4 and pre-8.4 queries, so that you don't need the LEFT JOIN in the pre-8.4 path. IMHO the cut-and-paste way that we usually do it in pg_dump is a whole lot easier to read and maintain than this sort of ?: spaghetti. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
This version should fix these issues. I refrained from adding more ? :
expressions because it starts getting ugly for my taste.
I think you might as well just introduce two separate code paths to
produce the 8.4 and pre-8.4 queries, so that you don't need the LEFT
JOIN in the pre-8.4 path.
Right, see attached. (Separating the last two cases is probably
overkill ...?) I tested with HEAD, 8.2 and 8.0, seems to work fine.
IMHO the cut-and-paste way that we usually
do it in pg_dump is a whole lot easier to read and maintain than this
sort of ?: spaghetti.
Hmm, so should we try to get rid of them in a more consistent fashion?
Index: src/bin/psql/describe.c
===
RCS file: /home/alvherre/cvs/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.198
diff -c -p -r1.198 describe.c
*** src/bin/psql/describe.c 22 Jan 2009 20:16:08 - 1.198
--- src/bin/psql/describe.c 11 Feb 2009 17:57:03 -
***
*** 8,14
*
* Copyright (c) 2000-2009, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/describe.c,v 1.198 2009-01-22 20:16:08 tgl Exp $
*/
#include postgres_fe.h
--- 8,14
*
* Copyright (c) 2000-2009, PostgreSQL Global Development Group
*
! * $PostgreSQL: pgsql/src/bin/psql/describe.c,v 1.197 2009/01/20 02:13:42 momjian Exp $
*/
#include postgres_fe.h
*** describeOneTableDetails(const char *sche
*** 909,924
initPQExpBuffer(tmpbuf);
/* Get general table info */
! printfPQExpBuffer(buf,
! SELECT relchecks, relkind, relhasindex, relhasrules, %s,
! relhasoids
! %s%s\n
! FROM pg_catalog.pg_class WHERE oid = '%s',
! (pset.sversion = 80400 ? relhastriggers : reltriggers 0),
! (pset.sversion = 80200 verbose ?
! , pg_catalog.array_to_string(reloptions, E', ') : ,''),
! (pset.sversion = 8 ? , reltablespace : ),
! oid);
res = PSQLexec(buf.data, false);
if (!res)
goto error_return;
--- 909,959
initPQExpBuffer(tmpbuf);
/* Get general table info */
! if (pset.sversion = 80400)
! {
! printfPQExpBuffer(buf,
! SELECT c.relchecks, c.relkind, c.relhasindex, c.relhasrules,
! c.relhastriggers, c.relhasoids,
! %s, c.reltablespace\n
! FROM pg_catalog.pg_class c\n
! LEFT JOIN pg_catalog.pg_class tc ON (c.reltoastrelid = tc.oid)\n
! WHERE c.oid = '%s'\n,
! (verbose ?
! pg_catalog.array_to_string(c.reloptions ||
! array(select 'toast.' || x from pg_catalog.unnest(tc.reloptions) x), ', ')\n
! : ''),
! oid);
! }
! else if (pset.sversion = 80200)
! {
! printfPQExpBuffer(buf,
! SELECT relchecks, relkind, relhasindex, relhasrules,
! reltriggers 0, relhasoids,
! %s, reltablespace\n
! FROM pg_catalog.pg_class WHERE oid = '%s',
! (verbose ?
! pg_catalog.array_to_string(reloptions, E', ') : ,''),
! oid);
! }
! else if (pset.sversion = 8)
! {
! printfPQExpBuffer(buf,
! SELECT relchecks, relkind, relhasindex, relhasrules,
! reltriggers 0, relhasoids,
! '', reltablespace\n
! FROM pg_catalog.pg_class WHERE oid = '%s',
! oid);
! }
! else
! {
! printfPQExpBuffer(buf,
! SELECT relchecks, relkind, relhasindex, relhasrules,
! reltriggers 0, relhasoids,
! '', ''\n
! FROM pg_catalog.pg_class WHERE oid = '%s',
! oid);
! }
!
res = PSQLexec(buf.data, false);
if (!res)
goto error_return;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane wrote: IMHO the cut-and-paste way that we usually do it in pg_dump is a whole lot easier to read and maintain than this sort of ?: spaghetti. Hmm, so should we try to get rid of them in a more consistent fashion? If you've got the time and interest to work on the rest of describe.c, it'd be fine with me. I don't feel a compulsion to go fix the rest right now, though. It just seemed that this particular query had gotten out of hand. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane wrote: IMHO the cut-and-paste way that we usually do it in pg_dump is a whole lot easier to read and maintain than this sort of ?: spaghetti. Hmm, so should we try to get rid of them in a more consistent fashion? If you've got the time and interest to work on the rest of describe.c, it'd be fine with me. I don't feel a compulsion to go fix the rest right now, though. It just seemed that this particular query had gotten out of hand. Yeah, I think we can get away with fixing the queries one by one as we go over them in future psql improvements. I have committed this for now. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Alvaro Herrera wrote: ITAGAKI Takahiro wrote: I tested this changes and found two issues: 1. fillfactor.* options are silently ignored when the table doesn't have toast relation. Should we notice the behabior to users? ex. NOTICE: toast storage parameters are ignored because the table doesn't have toast relations. You mean toast.* options? If so, yes, they are silently ignored. Maybe issuing a warning is not a bad idea. Care to propose a patch? Any takers here? The second issue has been solved. Thanks for testing. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Alvaro Herrera alvhe...@commandprompt.com writes: Alvaro Herrera wrote: ITAGAKI Takahiro wrote: 1. fillfactor.* options are silently ignored when the table doesn't have toast relation. Should we notice the behabior to users? ex. NOTICE: toast storage parameters are ignored You mean toast.* options? If so, yes, they are silently ignored. Maybe issuing a warning is not a bad idea. Care to propose a patch? Any takers here? I tend to think this isn't a very good idea. It's difficult for applications to know whether a toast table will be created or not. They should be able to just set the toast options and not worry. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Alvaro Herrera wrote: ITAGAKI Takahiro wrote: 1. fillfactor.* options are silently ignored when the table doesn't have toast relation. Should we notice the behabior to users? ex. NOTICE: toast storage parameters are ignored You mean toast.* options? If so, yes, they are silently ignored. Maybe issuing a warning is not a bad idea. Care to propose a patch? Any takers here? I tend to think this isn't a very good idea. It's difficult for applications to know whether a toast table will be created or not. They should be able to just set the toast options and not worry. The problem is where do we store the options? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Alvaro Herrera wrote: Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Alvaro Herrera wrote: ITAGAKI Takahiro wrote: 1. fillfactor.* options are silently ignored when the table doesn't have toast relation. Should we notice the behabior to users? ex. NOTICE: toast storage parameters are ignored You mean toast.* options? If so, yes, they are silently ignored. Maybe issuing a warning is not a bad idea. Care to propose a patch? Any takers here? I tend to think this isn't a very good idea. It's difficult for applications to know whether a toast table will be created or not. They should be able to just set the toast options and not worry. The problem is where do we store the options? How about in the reloptions of the main relation? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Heikki Linnakangas wrote: Alvaro Herrera wrote: Tom Lane wrote: I tend to think this isn't a very good idea. It's difficult for applications to know whether a toast table will be created or not. They should be able to just set the toast options and not worry. The problem is where do we store the options? How about in the reloptions of the main relation? Yes, perhaps that could be made to work. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane wrote: I tend to think this isn't a very good idea. It's difficult for applications to know whether a toast table will be created or not. They should be able to just set the toast options and not worry. The problem is where do we store the options? We don't. If there's no toast table, we don't need them after all. Now the alternative position you could take is that if someone is setting toast reloptions, they should darn well know the implementation well enough to know whether the table will have a toast table or not. In which case you should argue that this case ought to be an ERROR, not a notice or warning. But I think that's probably unsustainably anal. For example consider the following scenario: create table foo (f1 int, f2 text); set some toast reloptions on foo alter table foo drop column f2; pg_dump At this point foo still has a toast table and presumably pg_dump will dump its options. At reload, however, no toast table will be created, and so throwing an error would be pretty embarrassing. It's not hard to scale this up to find situations where the creation of a toast table would be platform- or version-dependent (if the max tuple width is just under a page). If we are not able to teach pg_dump to predict whether the target DB will create a toast table, we certainly can't expect applications to know it. So I think setting toast reloptions on a table that has no toast table should just be a silent no-op. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane wrote: I tend to think this isn't a very good idea. It's difficult for applications to know whether a toast table will be created or not. They should be able to just set the toast options and not worry. The problem is where do we store the options? We don't. If there's no toast table, we don't need them after all. Well, that's the position that the current code is taking. However, Takahiro-san and Euler's position is that if you do this: create table foo (f1 int) with (toast.fillfactor = 70); alter table foo add column f2 text; Then the toast table should have the fillfactor setting. Right now they are lost. If we agree that the options are OK to be lost, then there's nothing we need to do (and that's my opinion). If we don't, then we need some weird hack to make it work somehow. Personally I think that it needs a lot more work than it warrants. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Alvaro Herrera alvhe...@commandprompt.com writes: However, Takahiro-san and Euler's position is that if you do this: create table foo (f1 int) with (toast.fillfactor = 70); alter table foo add column f2 text; Then the toast table should have the fillfactor setting. Well, that might look sensible when phrased that way. But the more likely scenario would be that you add column f2 six months later, at which point there is room for pretty serious doubt that the option you specified way back when would still be the optimal choice. I'm just fine with the concept that if ADD COLUMN causes a toast table to get created, that table will have default reloptions. If you want nondefault toast reloptions, having to specify what you want after the table exists (and you know what's in it) seems reasonable to me. Or to put it another way: it seems to me that the use-case being argued here is really for being able to adjust the default toast reloptions. Not to have action at a distance on a table that doesn't exist and you have no way to know when you set the option what will be in it when it does exist. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Tom Lane wrote: Or to put it another way: it seems to me that the use-case being argued here is really for being able to adjust the default toast reloptions. Not to have action at a distance on a table that doesn't exist and you have no way to know when you set the option what will be in it when it does exist. This argument makes perfect sense to me. Since we don't have a way to set default reloptions for main tables either, I don't think we should be pushing very hard for having one to set default reloptions for toast tables. Even if we were to argue that we should have both, it doesn't seem material for 8.4. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Alvaro Herrera alvhe...@commandprompt.com writes: Since we don't have a way to set default reloptions for main tables either, I don't think we should be pushing very hard for having one to set default reloptions for toast tables. Even if we were to argue that we should have both, it doesn't seem material for 8.4. Seems like a reasonable TODO entry, though. I think the use-case for such a default mechanism is a bit thin today, but if we continue to push more functionality into reloptions it's going to become valuable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
On Wed, Feb 11, 2009 at 3:40 PM, Tom Lane t...@sss.pgh.pa.us wrote: Alvaro Herrera alvhe...@commandprompt.com writes: However, Takahiro-san and Euler's position is that if you do this: create table foo (f1 int) with (toast.fillfactor = 70); alter table foo add column f2 text; Then the toast table should have the fillfactor setting. Well, that might look sensible when phrased that way. But the more likely scenario would be that you add column f2 six months later, at which point there is room for pretty serious doubt that the option you specified way back when would still be the optimal choice. I'm just fine with the concept that if ADD COLUMN causes a toast table to get created, that table will have default reloptions. If you want nondefault toast reloptions, having to specify what you want after the table exists (and you know what's in it) seems reasonable to me. FWIW, I don't really buy this argument. I can't see that it's all that implausible to think that the user might be able to prognosticate a reasonable value for a future TOAST table. The fact that they may end up being wrong is hardly grounds to silently ignore whatever value they tell us they want. On the other hand, since I've never had a reason to tune this knob myself, for TOAST tables or otherwise, I can't say I'm feeling a violent urge to be the one to fix it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Robert Haas robertmh...@gmail.com writes: FWIW, I don't really buy this argument. I can't see that it's all that implausible to think that the user might be able to prognosticate a reasonable value for a future TOAST table. Well, it still seems to me that such a user is really more interested in a way to set the default toast fillfactor (or whatever option is under discussion), ie what he really knows is a reasonable value for *all* future TOAST tables in his installation. Otherwise you're arguing that he knows exactly what the fillfactor should be for a specific toast table and not any other one ... except he doesn't know when that toast table is going to be created, which calls into question the quality of his judgment about its specific behavior otherwise. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
On Wed, Feb 11, 2009 at 4:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: FWIW, I don't really buy this argument. I can't see that it's all that implausible to think that the user might be able to prognosticate a reasonable value for a future TOAST table. Well, it still seems to me that such a user is really more interested in a way to set the default toast fillfactor (or whatever option is under discussion), ie what he really knows is a reasonable value for *all* future TOAST tables in his installation. Maybe, or maybe he knows that this group of tables is typically pretty stable, but this group over here has more frequent updates, so different fillfactors are appropriate... doesn't have to be 100% site-wide. Otherwise you're arguing that he knows exactly what the fillfactor should be for a specific toast table and not any other one ... except he doesn't know when that toast table is going to be created, which calls into question the quality of his judgment about its specific behavior otherwise. Sure, but I think you're putting too much emphasis on the likely quality of the user's judgment. It's not really the place of the database to ignore user requests, even if they're likely stupid requests. WARNING: Type varchar(9) is likely inadequate for assumed purpose of column `telephone_number'. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Alvaro Herrera alvhe...@commandprompt.com writes: Note that it introduces a LEFT JOIN on pg_class to itself that's always present, even for server versions that do not support reloptions. Personally I'd be more worried about the unnest(). Also, please schema-qualify that function name; you can't assume anything about the search path here. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
