Re: [HACKERS] Syntax for partitioning

2009-10-28 Thread Pavel Stehule
2009/10/29 Itagaki Takahiro : > I'd like to improve partitioning feature in 8.5. > Kedar-san's previous work is wonderful, but I cannot see any updated patch. > http://archives.postgresql.org/message-id/bd8134a40906080702s96c90a9q3bbb581b9bd0d...@mail.gmail.com > > So, I'll take over the work if th

[HACKERS] Syntax for partitioning

2009-10-28 Thread Itagaki Takahiro
I'd like to improve partitioning feature in 8.5. Kedar-san's previous work is wonderful, but I cannot see any updated patch. http://archives.postgresql.org/message-id/bd8134a40906080702s96c90a9q3bbb581b9bd0d...@mail.gmail.com So, I'll take over the work if there are no ones to do it. I'm thinking

Re: [HACKERS] WIP: push AFTER-trigger execution into ModifyTable node

2009-10-28 Thread Robert Haas
On Wed, Oct 28, 2009 at 8:45 PM, Tom Lane wrote: > Marko Tiikkaja writes: >> Like we've discussed before, WITH (.. RETURNING ..) is probably most >> useful for moving rows from one table to another.  When you're moving a >> lot of rows around, there's some point where I believe this execution >>

Re: [HACKERS] WIP: push AFTER-trigger execution into ModifyTable node

2009-10-28 Thread Tom Lane
Marko Tiikkaja writes: > Like we've discussed before, WITH (.. RETURNING ..) is probably most > useful for moving rows from one table to another. When you're moving a > lot of rows around, there's some point where I believe this execution > strategy will be a lot slower than the traditional appro

Re: [HACKERS] WIP: push AFTER-trigger execution into ModifyTable node

2009-10-28 Thread Marko Tiikkaja
Tom Lane wrote: So, before I go off and do that work: anybody have an objection to this line of development? The main implication of changing to this approach is that we'll be nailing down the assumption that each WITH (command RETURNING) clause acts very much like a separate statement for trigg

[HACKERS] WIP: push AFTER-trigger execution into ModifyTable node

2009-10-28 Thread Tom Lane
In http://archives.postgresql.org/message-id/26545.1255140...@sss.pgh.pa.us I suggested that we should push the actual execution (not just queuing) of non-deferred AFTER triggers into the new ModifyTable plan node. The attached patch does that, and seems like a nice improvement since it removes kno

Re: [HACKERS] Show schema size with \dn+

2009-10-28 Thread Guillaume Lelarge
Le mercredi 28 octobre 2009 à 15:11:31, Anders Steinlein a écrit : > Is there any interest in expanding \dn+ to show schema size, similar > to table sizes using \dt+ in 8.4? We use separate schemas for each > user, so this would allow us to quickly look up the sizes of each > user's data. > > I ha

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Simon Riggs
On Tue, 2009-10-27 at 00:38 -0400, Greg Smith wrote: > new feature One additional point that would be useful is a way to match up the usage of custom_variable_classes with this new style of .conf file processing. At the moment if you wish to add a custom variable class everybody needs to edit the

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

2009-10-28 Thread Hannu Krosing
On Wed, 2009-10-28 at 15:31 -0400, Tom Lane wrote: > Hannu Krosing writes: > > I had never checked the docs for hash functions, but I had assumed, that > > internal functions are prefixed by pg_ and anything else is public, free > > to use functionality. > > Sure, it's free to use. It's not free

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Andrew Dunstan
Greg Smith wrote: On Wed, 28 Oct 2009, Josh Berkus wrote: It's the basic and unsolvable issue of how do you have a file which is both perfectly human-readable-and-editable *and* perfectly machine-readable-and-editable at the same time. Let's see...if I remember correctly from the last two r

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

2009-10-28 Thread Hannu Krosing
On Wed, 2009-10-28 at 12:51 -0700, Jeff Davis wrote: > On Wed, 2009-10-28 at 21:09 +0200, Hannu Krosing wrote: > > Is at least the fact that they "are undocumented, have changed in the > > past, and are likely to change again in the future" documented ? > > That's a little confusing to me: how do

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Robert Haas
On Wed, Oct 28, 2009 at 4:52 PM, Greg Smith wrote: > On Wed, 28 Oct 2009, Robert Haas wrote: > >> It would be completely logical to break up the configuration file into >> subfiles by TOPIC.  That would complicate things for tool-writers >> because they would need to get each setting into the prop

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Greg Smith
On Wed, 28 Oct 2009, Robert Haas wrote: It would be completely logical to break up the configuration file into subfiles by TOPIC. That would complicate things for tool-writers because they would need to get each setting into the proper file, and we currently don't have any infrastructure for th

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Robert Haas
On Wed, Oct 28, 2009 at 4:24 PM, Josh Berkus wrote: > >> Let's see...if I remember correctly from the last two rounds of this >> discussion, this is the point where someone pops up and says that >> switching to XML for the postgresql.conf will solve this problem. >> Whoever does that this time goe

Re: [HACKERS] alpha2 bundled -- please verify

2009-10-28 Thread Devrim GÜNDÜZ
On Wed, 2009-10-21 at 23:26 +0300, Peter Eisentraut wrote: > Alpha2 has been bundled and is available at > > http://developer.postgresql.org/~petere/alpha/ > > Please check that it is sane. Peter, could you please provide md5sum for alpha2 tarball? I know we missed in alpha1. It would be better

Re: [HACKERS] inefficient use of relation extension?

2009-10-28 Thread Alvaro Herrera
Tom Lane wrote: > Alvaro Herrera writes: > > I regularly (several times a day) see five or six processes all with > > pg_locks locktype=extend granted=f on the same table, waiting for a long > > time. > > I'm not sure what's causing that, but I *seriously* doubt that adding > new pages to FSM ri

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Josh Berkus
> Let's see...if I remember correctly from the last two rounds of this > discussion, this is the point where someone pops up and says that > switching to XML for the postgresql.conf will solve this problem. > Whoever does that this time goes into the ring with Kevin and I, but > they don't get a c

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Robert Haas
On Wed, Oct 28, 2009 at 3:28 PM, Tom Lane wrote: > Josh Berkus writes: >> Kevin, >>> Perhaps the ease of writing something like that with sed or perl has >>> caused me to underestimate the effort required in C.  I am curious >>> whether you actually mean that, or said it for rhetorical effect. >

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Greg Smith
On Wed, 28 Oct 2009, Josh Berkus wrote: It's the basic and unsolvable issue of how do you have a file which is both perfectly human-readable-and-editable *and* perfectly machine-readable-and-editable at the same time. Let's see...if I remember correctly from the last two rounds of this discus

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

2009-10-28 Thread Jeff Davis
On Wed, 2009-10-28 at 21:09 +0200, Hannu Krosing wrote: > Is at least the fact that they "are undocumented, have changed in the > past, and are likely to change again in the future" documented ? That's a little confusing to me: how do we document that something is undocumented? And where do we sto

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

2009-10-28 Thread Tom Lane
Kenneth Marshall writes: > On Wed, Oct 28, 2009 at 03:31:17PM -0400, Tom Lane wrote: >> Hash indexes are so far from being production-grade that this argument >> is not significant. > In addition that change from 8.3 -> 8.4 to store only the hash and not > the value in the index means that a rein

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

2009-10-28 Thread Kenneth Marshall
On Wed, Oct 28, 2009 at 03:31:17PM -0400, Tom Lane wrote: > Hannu Krosing writes: > > I had never checked the docs for hash functions, but I had assumed, that > > internal functions are prefixed by pg_ and anything else is public, free > > to use functionality. > > Sure, it's free to use. It's n

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

2009-10-28 Thread Tom Lane
Hannu Krosing writes: > I had never checked the docs for hash functions, but I had assumed, that > internal functions are prefixed by pg_ and anything else is public, free > to use functionality. Sure, it's free to use. It's not free to assume that we promise never to change it. > Changing hash

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Tom Lane
Josh Berkus writes: > Kevin, >> Perhaps the ease of writing something like that with sed or perl has >> caused me to underestimate the effort required in C. I am curious >> whether you actually mean that, or said it for rhetorical effect. > I actually mean that. It *looks* easy in perl, and in

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Greg Stark
On Wed, Oct 28, 2009 at 12:08 PM, Josh Berkus wrote: >> Perhaps the ease of writing something like that with sed or perl has >> caused me to underestimate the effort required in C.  I am curious >> whether you actually mean that, or said it for rhetorical effect. > > I actually mean that.  It *loo

Re: [HACKERS] [PATCHES] updated hash functions for postgresql v1

2009-10-28 Thread Hannu Krosing
On Wed, 2009-02-11 at 11:22 -0500, Tom Lane wrote: > Asko Oja writes: > > Did this change hashtext() visible to users? We have been using it quite > > widely for partitioning our databases. If so then it should be marked quite > > visibly in release notes as there might be others who will be hit b

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Josh Berkus
Kevin, > Perhaps the ease of writing something like that with sed or perl has > caused me to underestimate the effort required in C. I am curious > whether you actually mean that, or said it for rhetorical effect. I actually mean that. It *looks* easy in perl, and in fact *is* easy for *your* p

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Greg Stark
On Wed, Oct 28, 2009 at 10:28 AM, Greg Smith wrote: > The postgresql.conf file being modified is generated by initdb, and it's > already being customized per install by the initdb-time rules like detection > for maximum supported shared_buffers. It isn't one of the files installed by > the package

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Tom Lane
Greg Smith writes: > If as you say the only right way to do this is to use the flex logic, that > just reinforced how high the bar is for someone who wants to write a tool > that modifies the file. Yup, exactly. Personally I think that trying to auto-modify postgresql.conf is insane. The whol

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Kevin Grittner
Josh Berkus wrote: > The precedence issues you (and Robert) are citing are no different > from what we have currently in a single file. I think that's *why* we're mentioning it. This would seem to be the juncture to look for ways to improve that, not just settle for "no worse" -- but perhaps

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Greg Smith
On Wed, 28 Oct 2009, Greg Stark wrote: It's also a blatant violation of packaging rules for Debian if not every distribution. If you edit the user's configuration file then there's no way to install a modified default configuration file. You can't tell the automatic modifications apart from the

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Greg Smith
On Wed, 28 Oct 2009, Tom Lane wrote: Why in the world are you looking at initdb? The standard reference for postgresql.conf-reading code, by definition, is guc-file.l. I think the odds of building something that works right, without borrowing that same flex logic, are about nil. initdb was

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Josh Berkus
Kevin, > I'm talking about how the decision should be made as to which takes > precedence. It's fine to document which one *was* chosen, but that > doesn't eliminate the problem of conflicting settings making a mess. > Someone else (Robert maybe?) gave an explicit example of how three > files co

Re: [HACKERS] Where's the docs?

2009-10-28 Thread Josh Berkus
On 10/27/09 9:25 PM, Tom Lane wrote: > Josh Berkus writes: >> OK, this is the genuine failure; the syntax is missing for column triggers: > >> CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] } >> ON table [ FOR [ EACH ] { ROW | STATEMENT } ] >> EXECUTE PROCEDURE function_name (

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Greg Stark
On Wed, Oct 28, 2009 at 2:37 AM, Dimitri Fontaine wrote: > That's why I'm proposing the following API at file level: That's exactly the same as putting them all in the same file, only a different syntax. It still requires that any program understand what every other program was trying to do. >>

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Greg Stark
On Wed, Oct 28, 2009 at 7:33 AM, Alvaro Herrera wrote: > Greg Smith escribió: > >> This sounds familiar...oh, that's right, this is almost the same >> algorithm pgtune uses.  And it sucks, It's also a blatant violation of packaging rules for Debian if not every distribution. If you edit the user'

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Tom Lane
Greg Smith writes: > The sketched out design I have for a contrib/pgtune in C presumes that I'd > start by refactoring the relevant bits from initdb into a library for both > programs to use. But the initdb code doesn't care about preserving > existing values when making changes to them; it ju

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Greg Smith
On Wed, 28 Oct 2009, Alvaro Herrera wrote: Huh, isn't this code in initdb.c already? The sketched out design I have for a contrib/pgtune in C presumes that I'd start by refactoring the relevant bits from initdb into a library for both programs to use. But the initdb code doesn't care about

[HACKERS] FOR UPDATE versus outer joins

2009-10-28 Thread Tom Lane
While I'm fooling with the FOR UPDATE code ... Currently, you can't apply FOR UPDATE to a relation that's on the inner side of an outer join, eg regression=# select * from a left join b using(aa) for update; ERROR: SELECT FOR UPDATE/SHARE cannot be applied to the nullable side of an outer join

[HACKERS] Show schema size with \dn+

2009-10-28 Thread Anders Steinlein
Is there any interest in expanding \dn+ to show schema size, similar to table sizes using \dt+ in 8.4? We use separate schemas for each user, so this would allow us to quickly look up the sizes of each user's data. I have little experience with C and none with the PostgreSQL code base --

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Kevin Grittner
Alvaro Herrera wrote: > Kevin Grittner wrote: > >> But I think that's where the rub is -- when you >> have more than one source for information, what's the precedence? > > This is not a problem nowadays because that info is in pg_settings. > File name and line number. I'm talking about how th

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Andrew Dunstan
Alvaro Herrera wrote: Greg Smith escribió: I was thinking that the algorithm would be something like: "Read the old postgresql.conf and write it back out to a new file line by line This sounds familiar...oh, that's right, this is almost the same algorithm pgtune uses. And it s

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Alvaro Herrera
Kevin Grittner wrote: > But I think that's where the rub is -- when you > have more than one source for information, what's the precedence? This is not a problem nowadays because that info is in pg_settings. File name and line number. -- Alvaro Herrerahttp://www

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Alvaro Herrera
Greg Smith escribió: > >I was thinking that the algorithm would be something like: "Read > >the old postgresql.conf and write it back out to a new file line > >by line > > This sounds familiar...oh, that's right, this is almost the same > algorithm pgtune uses. And it sucks, and it's a pain

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Kevin Grittner
Forgive me for jumping in again on discussion of a feature I might never use, but as an "outside observer" something doesn't make sense to me. Josh Berkus wrote: > If you require that a tool (or SET PERISTENT) parse through a file > in order to change one setting, then you've just doubled or t

Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

2009-10-28 Thread Alvaro Herrera
KaiGai Kohei escribió: > Alvaro Herrera wrote: > >Now, let's assume that COPY data includes the security context for each > >tuple in the output. > > When we support row-level security, it will be necessary to backup and > restore the security context for each tuples. Oh, right, that part is bei

Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

2009-10-28 Thread KaiGai Kohei
Alvaro Herrera wrote: KaiGai Kohei escribió: There are two cases when we create a new object. 1) create a new object without any explicit security context. If we don't have statement support, it is the only case. In this case, SELinux computes a default security context to be assigned on the n

Re: [HACKERS] Where's the docs?

2009-10-28 Thread Tom Lane
Peter Eisentraut writes: > On Wed, 2009-10-28 at 00:25 -0400, Tom Lane wrote: >> Josh Berkus writes: >>> OK, this is the genuine failure; the syntax is missing for column triggers: >>> CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] } >>> ON table [ FOR [ EACH ] { ROW | STATEMENT } ] >

Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

2009-10-28 Thread Alvaro Herrera
KaiGai Kohei escribió: > There are two cases when we create a new object. > > 1) create a new object without any explicit security context. > If we don't have statement support, it is the only case. > In this case, SELinux computes a default security context to be assigned > on the new object. It

Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

2009-10-28 Thread KaiGai Kohei
Heikki Linnakangas wrote: KaiGai Kohei wrote: Heikki Linnakangas wrote: KaiGai Kohei wrote: Robert Haas wrote: 2009/10/27 KaiGai Kohei : - no statement support to specify security context. (It makes impossible to add support in pg_dump. Is it really OK?) I doubt that anything without pg_du

Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

2009-10-28 Thread Heikki Linnakangas
KaiGai Kohei wrote: > Heikki Linnakangas wrote: >> KaiGai Kohei wrote: >>> Robert Haas wrote: 2009/10/27 KaiGai Kohei : > - no statement support to specify security context. > (It makes impossible to add support in pg_dump. Is it really OK?) I doubt that anything without pg_dump

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Robert Haas
On Tue, Oct 27, 2009 at 11:40 PM, Josh Berkus wrote: > On 10/27/09 8:24 PM, Robert Haas wrote: >> read the old postgresql.conf and >> write it back out to a new file line by line.  If, in the process of >> doing this, you find a setting for the variable you're trying to >> change, then write out t

Re: [HACKERS] Parsing config files in a directory

2009-10-28 Thread Dimitri Fontaine
Greg Stark writes: > On Tue, Oct 27, 2009 at 8:40 PM, Josh Berkus wrote: >> You're hearing from the people who are working on tools: requiring that >> any tool parse a hand-written config file is a non-starter. > > It can be done, pgadmin actually does it currently. But I totally > agree it's a b

Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

2009-10-28 Thread KaiGai Kohei
Heikki Linnakangas wrote: > KaiGai Kohei wrote: >> Robert Haas wrote: >>> 2009/10/27 KaiGai Kohei : - no statement support to specify security context. (It makes impossible to add support in pg_dump. Is it really OK?) >>> I doubt that anything without pg_dump support would be even vaguel

Re: [HACKERS] SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

2009-10-28 Thread Heikki Linnakangas
KaiGai Kohei wrote: > Robert Haas wrote: >> 2009/10/27 KaiGai Kohei : >>> - no statement support to specify security context. >>> (It makes impossible to add support in pg_dump. Is it really OK?) >> I doubt that anything without pg_dump support would be even vaguely OK... > > In my previous exper