Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Martijn van Oosterhout
On Sun, Aug 24, 2008 at 09:24:23PM -0400, Tom Lane wrote: My own feeling is that we should avoid imputing particular semantics to particular operator names, and so these constructs should always be defined by reference to operators found in a default opclass for the datatype, rather than by

Re: [HACKERS] Extending grant insert on tables to sequences

2008-08-25 Thread Jaime Casanova
On Fri, Aug 22, 2008 at 10:19 PM, Bruce Momjian [EMAIL PROTECTED] wrote: Added to September commit fest. why? there isn't a new patch yet... i haven't sent it because i want to see the column level privileges patch first because Tom's complaints -- regards, Jaime Casanova Soporte y

Re: [HACKERS] proposal sql: labeled function params

2008-08-25 Thread Pavel Stehule
Hello 2008/8/24 Martijn van Oosterhout [EMAIL PROTECTED]: On Sun, Aug 24, 2008 at 12:00:01PM -0400, Tom Lane wrote: So I feel that the proposal for labeled parameters as such is dead in the water, and that the only usefulness this thread has had is (re-) exploring the syntactic alternatives

Re: [HACKERS] [PATCHES] VACUUM Improvements - WIP Patch

2008-08-25 Thread Heikki Linnakangas
Tom Lane wrote: [ off-list ] Matthew T. O'Connor [EMAIL PROTECTED] writes: Tom Lane wrote: I'm not sure how important it will really be once we have support for dead-space-map-driven vacuum. Is that something we can expect any time soon? I haven't heard much about it really happening for

Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Dimitri Fontaine
Le lundi 25 août 2008, Martijn van Oosterhout a écrit : ISTM the problem is that there's no easy way to refer to operators found in a default opclass, so perhaps we could invent a construct: Perhaps here again we're showing a need for some higher level semantics about operators and types. The

Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Gregory Stark
Dimitri Fontaine [EMAIL PROTECTED] writes: Le lundi 25 août 2008, Martijn van Oosterhout a écrit : ISTM the problem is that there's no easy way to refer to operators found in a default opclass, so perhaps we could invent a construct: Perhaps here again we're showing a need for some higher

Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Dimitri Fontaine
Le lundi 25 août 2008, Gregory Stark a écrit : I'm not sure it's made explicit anywhere in the documentation but those properties *are* what btree operator classes define. You would end up duplicating the same structures (like, LT is meaningless unless you associate it with the corresponding

Re: [HACKERS] can't stop autovacuum by HUP'ing the server

2008-08-25 Thread Dave Cramer
On 24-Aug-08, at 10:12 PM, Tom Lane wrote: Dave Cramer [EMAIL PROTECTED] writes: I'd like to stop autovac by changing the conf file then sending the server a HUP Uh ... why should that stop an autovac already in progress? I'd only expect it to affect future launches. Well, I go the

Re: [HACKERS] can't stop autovacuum by HUP'ing the server

2008-08-25 Thread Dave Cramer
On 24-Aug-08, at 10:17 PM, Alvaro Herrera wrote: Hi Dave, Dave Cramer wrote: I'd like to stop autovac by changing the conf file then sending the server a HUP This appears to work, the logs show autovac terminated by administrative command. Then a few minutes later I see a vacuum process

Re: [HACKERS] can't stop autovacuum by HUP'ing the server

2008-08-25 Thread Alvaro Herrera
Dave Cramer wrote: Since a number of people actually do this it would seem like a better way to temporarily suspend autovac should be on the todo ? No -- what you are doing is documented to work. However, it only stops the autovac launcher, not a currently-running worker. If this isn't

Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Peter Eisentraut
On Monday 25 August 2008 04:24:23 Tom Lane wrote: Seems to me that what this boils down to is whether we want to read the spec literally (it says the construct is defined in terms of operators named = and =, therefore we should do that) or by intent (obviously what they *want* is a construct

Re: [HACKERS] can't stop autovacuum by HUP'ing the server

2008-08-25 Thread Alvaro Herrera
Dave Cramer wrote: Well, I go the extra mile and kill any remaing autovac procs Here are the logs 2008-08-25 04:00:01 EDT [32276] LOG: autovacuum launcher shutting down 2008-08-25 04:00:01 EDT [20526] LOG: autovacuum launcher started What did you SIGHUP, the launcher or postmaster?

Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Tom Lane
Martijn van Oosterhout [EMAIL PROTECTED] writes: On Sun, Aug 24, 2008 at 09:24:23PM -0400, Tom Lane wrote: My own feeling is that we should avoid imputing particular semantics to particular operator names, and so these constructs should always be defined by reference to operators found in a

Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Tom Lane
Dimitri Fontaine [EMAIL PROTECTED] writes: Le lundi 25 août 2008, Gregory Stark a écrit : I'm not sure it's made explicit anywhere in the documentation but those properties *are* what btree operator classes define. You would end up duplicating the same structures (like, LT is meaningless

Re: [HACKERS] temporary statistics option at initdb time

2008-08-25 Thread Magnus Hagander
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Actually, I think maybe not so hard. Attached is a patch that fixes this. It's done by keeping the old filename around. When you change the path, the stats collector will start writing the new file the next time it writes something

[HACKERS] Another refactoring proposal: move stuff into nodes/nodeFuncs.[ch]

2008-08-25 Thread Tom Lane
So I was starting to implement an exprLocation() function according to previous discussion http://archives.postgresql.org/pgsql-hackers/2008-08/msg01131.php and I wondered where to put it. One idea is next to exprType() in parser/parse_expr.c, but that seems a bit unsatisfactory because it's

Re: [HACKERS] temporary statistics option at initdb time

2008-08-25 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: I think this is introducing complication and race conditions to solve a problem that no one will really care about. Just let people change the filename at SIGHUP and document that doing that on-the-fly may cause stats queries to fail

Re: [HACKERS] temporary statistics option at initdb time

2008-08-25 Thread Magnus Hagander
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: I think this is introducing complication and race conditions to solve a problem that no one will really care about. Just let people change the filename at SIGHUP and document that doing that on-the-fly may cause stats

Re: [HACKERS] temporary statistics option at initdb time

2008-08-25 Thread Tom Lane
I wrote: [ squint... ] Actually, it looks like the stats collector SIG_IGNores SIGHUP? That can't be right (any more) can it? Oh, never mind, I see my hour-old CVS pull is obsolete ... regards, tom lane -- Sent via pgsql-hackers mailing list

[HACKERS] initdb change

2008-08-25 Thread David Fetter
Folks, While initdb allows you to choose a directory for transaction logs, it can't already exist, so it can't be in its usual place under $PGDATA. I'd like to propose that this be allowed by having an alternate syntax for the -X option, namely, existing. When -X is set to existing, it would

Re: [HACKERS] initdb change

2008-08-25 Thread Tom Lane
David Fetter [EMAIL PROTECTED] writes: While initdb allows you to choose a directory for transaction logs, it can't already exist, so it can't be in its usual place under $PGDATA. I'd like to propose that this be allowed by having an alternate syntax for the -X option, namely, existing. When

Re: [HACKERS] initdb change

2008-08-25 Thread Joshua Drake
On Mon, 25 Aug 2008 08:40:17 -0700 David Fetter [EMAIL PROTECTED] wrote: Folks, While initdb allows you to choose a directory for transaction logs, it can't already exist, so it can't be in its usual place under $PGDATA. I'd like to propose that this be allowed by having an alternate syntax

Re: [HACKERS] initdb change

2008-08-25 Thread David Fetter
On Mon, Aug 25, 2008 at 11:48:29AM -0400, Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: While initdb allows you to choose a directory for transaction logs, it can't already exist, so it can't be in its usual place under $PGDATA. I'd like to propose that this be allowed by having

Re: [HACKERS] initdb change

2008-08-25 Thread Joshua Drake
On Mon, 25 Aug 2008 09:04:01 -0700 David Fetter [EMAIL PROTECTED] wrote: When -X is set to existing, it would check whether pg_xlog is a directory and the only thing in $PGDATA. One way to do that is to add a new return code to check_data_dir() and a new branch of the case statement

Re: [HACKERS] initdb change

2008-08-25 Thread David Fetter
On Mon, Aug 25, 2008 at 09:29:03AM -0700, Joshua D. Drake wrote: On Mon, 25 Aug 2008 09:04:01 -0700 David Fetter [EMAIL PROTECTED] wrote: When -X is set to existing, it would check whether pg_xlog is a directory and the only thing in $PGDATA. One way to do that is to add a new

Re: [HACKERS] initdb change

2008-08-25 Thread Joshua Drake
On Mon, 25 Aug 2008 09:42:21 -0700 David Fetter [EMAIL PROTECTED] wrote: We either need to provide a way to initialize it at initdb, allow xlogs to be in table space or add a GUC for the location. There's already a way to specify where xlogs should be via -X/--xlogdir. Sorry should have

Re: [HACKERS] initdb change

2008-08-25 Thread Heikki Linnakangas
David Fetter wrote: There's already a way to specify where xlogs should be via -X/--xlogdir. What that doesn't do is put the xlogdir where a DBA would naturally expect to find it. When that DBA doesn't find it in the place they expect, very bad knock-on decisions are likely to result. I

Re: [HACKERS] can't stop autovacuum by HUP'ing the server

2008-08-25 Thread Dave Cramer
On 25-Aug-08, at 10:43 AM, Alvaro Herrera wrote: Dave Cramer wrote: Well, I go the extra mile and kill any remaing autovac procs Here are the logs 2008-08-25 04:00:01 EDT [32276] LOG: autovacuum launcher shutting down 2008-08-25 04:00:01 EDT [20526] LOG: autovacuum launcher started

Re: [HACKERS] initdb change

2008-08-25 Thread Andrew Dunstan
David Fetter wrote: On Mon, Aug 25, 2008 at 11:48:29AM -0400, Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: While initdb allows you to choose a directory for transaction logs, it can't already exist, so it can't be in its usual place under $PGDATA. I'd like to propose that

Re: [HACKERS] initdb change

2008-08-25 Thread David Fetter
On Mon, Aug 25, 2008 at 09:54:26AM -0700, Joshua D. Drake wrote: On Mon, 25 Aug 2008 09:42:21 -0700 David Fetter [EMAIL PROTECTED] wrote: We either need to provide a way to initialize it at initdb, allow xlogs to be in table space or add a GUC for the location. There's already a way

Re: [HACKERS] initdb change

2008-08-25 Thread Joshua Drake
On Mon, 25 Aug 2008 10:12:03 -0700 David Fetter [EMAIL PROTECTED] wrote: /var/lib/pgsql/data/ exists but is empty you can initdb within that directory. However if there is anything in it you can not. You are asking that if pg_xlog exists but is empty that we still be able to use the

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

2008-08-25 Thread Jeff Davis
On Sun, 2008-06-29 at 16:57 -0400, Tom Lane wrote: After playing with it for a little bit, I'm not convinced that it buys enough performance win to be worth applying --- the restriction of cache lifespan to one tuple cycle of a TupleTableSlot is awfully restrictive. (For example, sorts that

Re: [HACKERS] initdb change

2008-08-25 Thread Andrew Dunstan
Joshua Drake wrote: Is there some reason why initdb shouldn't just Do The Right Thing™ when it finds an empty extant $PGDATA/pg_xlog directory that passes the same tests an empty extant $PGDATA would? That is what I was suggesting. Why should the xlog directory be treated

Re: [HACKERS] initdb change

2008-08-25 Thread Joshua Drake
On Mon, 25 Aug 2008 13:56:16 -0400 Andrew Dunstan [EMAIL PROTECTED] wrote: That is what I was suggesting. Why should the xlog directory be treated specially? Consider the following: mount /dev/sda1 /var/lib/pgsql mount /dev/sdb1 /srv1/pgsql/pg_xlog (which has a link from

Re: [HACKERS] Proposal: new border setting in psql

2008-08-25 Thread Steve Atkins
On Aug 24, 2008, at 6:16 AM, Merlin Moncure wrote: On Sun, Aug 24, 2008 at 2:00 AM, D'Arcy J.M. Cain [EMAIL PROTECTED] wrote: On Sat, 23 Aug 2008 14:57:50 -0400 Tom Lane [EMAIL PROTECTED] wrote: Also, having now looked at the proposed patch, it seems clear that it isn't addressing the

Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Dimitri Fontaine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Le 25 août 08 à 16:48, Tom Lane a écrit : But, IIRC, only in the context of index searches, not at the planner level. No, that's not true at all. There are lots and lots of places now where we use btree and/or hash operator classes to

Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Tom Lane
Dimitri Fontaine [EMAIL PROTECTED] writes: ... I don't really see any theorical need for opclass if it's not for indexing. Well, if we were starting from a green field, we might design it differently, but I see little point in changing the system structure now that it's established. You need

Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Nathan Boley
Yes, but always in relation to operator classes, so from BTrees opclass or such, which I refered to as the context of index searches, as I don't really see any theorical need for opclass if it's not for indexing. IIRC analyze uses the btree op class to build the selectivity histogram. -Nathan

Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Martijn van Oosterhout
On Mon, Aug 25, 2008 at 10:43:30AM -0400, Tom Lane wrote: Martijn van Oosterhout [EMAIL PROTECTED] writes: ISTM the problem is that there's no easy way to refer to operators found in a default opclass, so perhaps we could invent a construct: A OPERATOR(btree,2) B Huh? I don't

Re: [HACKERS] IN, BETWEEN, spec compliance, and odd operator names

2008-08-25 Thread Tom Lane
Martijn van Oosterhout [EMAIL PROTECTED] writes: On Mon, Aug 25, 2008 at 10:43:30AM -0400, Tom Lane wrote: To me the issue is what we consider IN and BETWEEN and similar constructs to mean, which in a datatype world boils down to choosing which of the datatype's operators to implement the

[HACKERS] Implementing cost limit/delays for insert/delete/update/select

2008-08-25 Thread Peter Schuller
Hello, I'd like to have a stab at implementing cost delays, for regular INSERT/DELETE/UPDATE/SELECT. The motivation is roughly the same as for VACUUM and the autovacuum limits; one may have application specific bulk operations that need executing without adverseley affecting latency/throughput of

Re: [HACKERS] Should enum GUCs be listed as such in config.sgml?

2008-08-25 Thread Magnus Hagander
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: bruce wrote: Tom Lane wrote: Currently, config.sgml still describes the new enum GUC variables as being of type string --- but pg_settings says they are enum. This is not very consistent, but I wonder whether changing the docs would be

Re: [HACKERS] Implementing cost limit/delays for insert/delete/update/select

2008-08-25 Thread Gregory Stark
Peter Schuller [EMAIL PROTECTED] writes: Hello, I'd like to have a stab at implementing cost delays, for regular INSERT/DELETE/UPDATE/SELECT. The motivation is roughly the same as for VACUUM and the autovacuum limits; one may have application specific bulk operations that need executing

Re: [HACKERS] Implementing cost limit/delays for insert/delete/update/select

2008-08-25 Thread Joshua Drake
On Mon, 25 Aug 2008 22:39:54 +0100 Gregory Stark [EMAIL PROTECTED] wrote: But I think we should consider removing the {auto,}vacuum_cost_delay parameter or at least hiding and undocumenting it. It's a foot-gun and serves no useful purpose that merely lowering the {auto,}vacuum_cost_limit

Re: [HACKERS] Implementing cost limit/delays for insert/delete/update/select

2008-08-25 Thread Peter Schuller
Btw, I forgot to mention in my original post that one interesting use case that is not application specific, is to apply cost limits on pg_dump. That would be one of the final goals for me. I think the experience with vacuum was that cost_delay was a mistake. The only parameter users really

[HACKERS] Proposal to sync SET ROLE and pg_stat_activity

2008-08-25 Thread Grant Finnemore
Hi, In the manual for SET ROLE, it's noted that an invocation of SET ROLE will leave the session_user unchanged, but will change the current_user. Invoking pg_stat_activity after the SET ROLE is changed will however leave the usename unchanged. (Also from the manual we note that a snapshot is

Re: [HACKERS] Implementing cost limit/delays for insert/delete/update/select

2008-08-25 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes: You would have to test for whether it's time to sleep much more often. Possibly before every ExecProcNode call would be enough. That would have overhead comparable to EXPLAIN ANALYZE, which is a lot. I'm fairly dubious about this whole proposal: it's not

Re: [HACKERS] Implementing cost limit/delays for insert/delete/update/select

2008-08-25 Thread Gregory Stark
Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] writes: You would have to test for whether it's time to sleep much more often. Possibly before every ExecProcNode call would be enough. That would have overhead comparable to EXPLAIN ANALYZE, which is a lot. I don't think

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

2008-08-25 Thread Tom Lane
Jeff Davis [EMAIL PROTECTED] writes: On Sun, 2008-06-29 at 16:57 -0400, Tom Lane wrote: After playing with it for a little bit, I'm not convinced that it buys enough performance win to be worth applying --- the restriction of cache lifespan to one tuple cycle of a TupleTableSlot is awfully

Re: [HACKERS] Proposal: new border setting in psql

2008-08-25 Thread Tom Lane
Steve Atkins [EMAIL PROTECTED] writes: On Aug 24, 2008, at 6:16 AM, Merlin Moncure wrote: Personally I think it's rather nice to be able to have some extra flexibility in how psql prints out data. Maybe, instead of the dry and uninformative 'border 2', there could be a set of ouput control

[HACKERS] Split up the wiki TODO page?

2008-08-25 Thread Tom Lane
So, if you edit the current version of the TODO page, you get this stern warning: WARNING: This page is 106 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections. Hmm ... my browser isn't failing,

Re: [HACKERS] Split up the wiki TODO page?

2008-08-25 Thread Joshua D. Drake
Tom Lane wrote: So, if you edit the current version of the TODO page, you get this stern warning: WARNING: This page is 106 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections. Hmm ... my