Re: [HACKERS] function attributes

On Dec 11, 2010, at 5:58 PM, Andrew Dunstan wrote: > create function foo() . with ( /attribute/ [, ...] ) > > Currently allowed attributes are isStrict and isCachable. The mechanism is > effectively obsolete right now, but we could use it for what I have in mind > quite nicely. Makes s

[HACKERS] proposal : cross-column stats

Hi everyone, one of the ssesion I've attended on PgDay last week was Heikki's session about statistics in PostgreSQL. One of the issues he mentioned (and one I regularly run into) is the absence of cross-column stats. When the columns are not independent, this usually result in poor estimates (and

Re: [HACKERS] keeping a timestamp of the last stats reset (for a db, table and function)

On Sat, Dec 11, 2010 at 4:40 PM, wrote: >> Hello >> >> you have to respect pg coding style: >> >> a) not too long lines >> b) not C++ line comments > > OK, thanks for the notice. I've fixed those two problems. Please add this to the currently-open commitfest. https://commitfest.postgresql.org/a

Re: [HACKERS] function attributes

On Sat, Dec 11, 2010 at 9:28 PM, Andrew Dunstan wrote: > On 12/11/2010 09:16 PM, Robert Haas wrote: >> >> Well, you could set that GUC (plperl.pass_binary_bytea) on a function >> without changing any syntax on at all. >> >> CREATE FUNCTION name (args) ... SET plperl.pass_binary_bytea = true; > > O

Re: [HACKERS] unlogged tables

On Sat, Dec 11, 2010 at 9:21 PM, Jeff Janes wrote: > On Fri, Dec 10, 2010 at 8:16 PM, Robert Haas wrote: > >> I think the first patch (relpersistence-v4.patch) is ready to commit, >> and the third patch to allow synchronous commits to become >> asynchronous when it doesn't matter (relax-sync-comm

Re: [HACKERS] function attributes

On 12/11/2010 09:16 PM, Robert Haas wrote: Well, you could set that GUC (plperl.pass_binary_bytea) on a function without changing any syntax on at all. CREATE FUNCTION name (args) ... SET plperl.pass_binary_bytea = true; Oh, good point. I'd forgotten about that. I'll experiment and see if I

Re: [HACKERS] unlogged tables

On Fri, Dec 10, 2010 at 8:16 PM, Robert Haas wrote: > I think the first patch (relpersistence-v4.patch) is ready to commit, > and the third patch to allow synchronous commits to become > asynchronous when it doesn't matter (relax-sync-commit-v1.patch) > doesn't seem to be changing much either, al

Re: [HACKERS] function attributes

On Sat, Dec 11, 2010 at 5:27 PM, Andrew Dunstan wrote: > Yesterday I did a bit of work on allowing bytea values to be passed into and > out of plperl in binary format, effectively removing the need to escape and > de-escape them. (The work can be seen on he plperlargs branch of my > development re

Re: [HACKERS] unlogged tables

On Sat, Dec 11, 2010 at 3:18 PM, Jeff Janes wrote: > On Fri, Dec 10, 2010 at 8:16 PM, Robert Haas wrote: >> >> As I was working on the hash index support, it occurred to me that at >> some point in the future, we might want to allow an unlogged index on >> a permanent table. > > That is the featu

Re: [HACKERS] unlogged tables

On Sat, Dec 11, 2010 at 2:53 PM, Jeff Janes wrote: > On Wed, Dec 8, 2010 at 6:52 AM, Marti Raudsepp wrote: >> A very useful feature for unlogged tables would be the ability to >> switch them back to normal tables -- this way you could do bulk >> loading into an unlogged table and then turn it int

Re: [HACKERS] function attributes

On 12/11/2010 08:01 PM, David E. Wheeler wrote: At the moment the behaviour is triggered by a custom setting (plperl.pass_binary_bytea), but this isn't really satisfactory. We could turn it on permanently, but that would break a lot of legacy code. What we really need is a way of marking

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

On Sat, Dec 11, 2010 at 1:38 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, Dec 11, 2010 at 1:20 PM, Tom Lane wrote: >>> I'm not really thinking about crash recovery, but replication slaves. >>> Omitting to create the tablespace location directories on slaves >>> doesn't seem far-fetched a

Re: [HACKERS] function attributes

On Dec 11, 2010, at 2:27 PM, Andrew Dunstan wrote: > Yesterday I did a bit of work on allowing bytea values to be passed into and > out of plperl in binary format, effectively removing the need to escape and > de-escape them. (The work can be seen on he plperlargs branch of my > development rep

[HACKERS] function attributes

Yesterday I did a bit of work on allowing bytea values to be passed into and out of plperl in binary format, effectively removing the need to escape and de-escape them. (The work can be seen on he plperlargs branch of my development repo at

Re: [HACKERS] proposal: auxiliary functions for record type

Hello I looked on your module now and I am can't to say, what is better - both modules has little bit different target if I understand, and I don't know if they can be mixed. There are two strategies - rich contrib module or a few functions in core. Probably we can't to have a too rich API for rec

Re: [HACKERS] proposal: auxiliary functions for record type

On Dec 11, 2010, at 9:24 AM, Florian Pflug wrote: > begin > for v_field in select * from fieldinfos(myrec) loop > case > when v_field.fieldtype = 'type1'::regtype then > v_value_type1 := fieldvalue(myrec, NULL::type1, > false)

Re: [HACKERS] keeping a timestamp of the last stats reset (for a db, table and function)

> Hello > > you have to respect pg coding style: > > a) not too long lines > b) not C++ line comments OK, thanks for the notice. I've fixed those two problems. regards Tomasdiff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql index 346eaaf..0ee59b1 100644 ---

Re: [HACKERS] would hw acceleration help postgres (databases in general) ?

On Dec 10, 2010, at 6:18 PM, Jeff Janes wrote: > On Fri, Dec 10, 2010 at 3:09 PM, Hamza Bin Sohail wrote: >> >> Hello hackers, >> >> I think i'm at the right place to ask this question. >> >> Based on your experience and the fact that you have written the Postgres >> code, >> can you tell what

Re: [HACKERS] ALTER EXTENSION ... UPGRADE;

On Dec 11, 2010, at 12:09 PM, Dimitri Fontaine wrote: > Yeah that works, as soon as VVV is the version we upgrade from. > > That said, we need to find a way to lighten the process for extensions > where it's easy to have a single script to support upgrade from more > than once past release. > >

Re: [HACKERS] Extensions, patch v16

On Dec 11, 2010, at 1:09 PM, David Fetter wrote: >> Why is it in the makefile at all? If the makefile does need to know it, >> why don't we have it scrape the number out of the control file? Or even >> more to the point, since when do we need version numbers in extensions? > > We *absolutely* n

Re: [HACKERS] keeping a timestamp of the last stats reset (for a db, table and function)

Hello you have to respect pg coding style: a) not too long lines b) not C++ line comments Zdar Pavel 2010/12/11 : > Hi everyone, > > I just wrote my first patch, and I need to know whether I missed something > or not. I haven't used C for a really long time, so sickbags on standby, > and if y

Re: [HACKERS] proposal: auxiliary functions for record type

2010/12/11 Florian Pflug : > On Dec11, 2010, at 17:55 , Pavel Stehule wrote: >> It same trick, that I use in record_set_fields. > Oh, I see. Sorry, must haven missed that when I read your blog entry. > >> But I don't want to >> use it for reading of value. I don't like it. You don't need to know a

Re: [HACKERS] Extensions, patch v16

On Fri, Dec 10, 2010 at 11:24:27AM -0500, Tom Lane wrote: > Dimitri Fontaine writes: > > Tom Lane writes: > >> Are there any actual remaining use-cases for that sed step? > > > The goal here is to allow extension authors to maintain their version > > number in the Makefile rather than in the Mak

[HACKERS] pg_execute_from_file, patch v10

Hi, The other infrastructure patch that has been mark ready for commit then commented further upon by Tom is $subject, even if the function provided as been renamed to pg_execute_sql_file(). Please find attached the newer version that fixes Tom concerns, removing the VARIADIC forms of the functio

[HACKERS] Wildcard search support for pg_trgm

Hackers, Here is first version of patch, which enable index support of wildcard search in pg_trgm contrib module. The idea of the patch is to extract from wildcard trigrams which should occurs in wildcard matching string. For example, for '%sector%' wildcard such trigrams would be: 'sec', 'ect', '

[HACKERS] Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records

(Moving to pgsql-hackers) On 10.12.2010 20:21, Tom Lane wrote: Simon Riggs writes: Reduce spurious Hot Standby conflicts from never-visible records. Hot Standby conflicts only with tuples that were visible at some point. So ignore tuples from aborted transactions or for tuples updated/deleted

Re: [HACKERS] proposal: auxiliary functions for record type

On Dec11, 2010, at 17:55 , Pavel Stehule wrote: > It same trick, that I use in record_set_fields. Oh, I see. Sorry, must haven missed that when I read your blog entry. > But I don't want to > use it for reading of value. I don't like it. You don't need to know a > value, you have to know a type -

Re: [HACKERS] unlogged tables

On Fri, Dec 10, 2010 at 8:16 PM, Robert Haas wrote: > > As I was working on the hash index support, it occurred to me that at > some point in the future, we might want to allow an unlogged index on > a permanent table. That is the feature I would be most excited about. > With the current patch,

Re: [HACKERS] ALTER EXTENSION ... UPGRADE;

Hi, I've been reading through the entire thread and it seems like this is the best mail to choose to answer. Tom Lane writes: > Maybe I misread David's meaning, but I thought he was saying that > there's no value in inventing all those control file entries in the > first place. Just hard-wire i

Re: [HACKERS] unlogged tables

On Wed, Dec 8, 2010 at 6:52 AM, Marti Raudsepp wrote: > A very useful feature for unlogged tables would be the ability to > switch them back to normal tables -- this way you could do bulk > loading into an unlogged table and then turn it into a regular table > using just fsync(), bypassing all the

Re: [HACKERS] Anyone for SSDs?

On Fri, Dec 10, 2010 at 8:09 PM, Vaibhav Kaushal wrote: > On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote: >> On 12/10/10 5:06 PM, Daniel Loureiro wrote: >> > An quicksort method in >> > sequential disk its just awful to be thinking in a non SSD world, but >> > its possible in an SSD. >> >> S

[HACKERS] keeping a timestamp of the last stats reset (for a db, table and function)

Hi everyone, I just wrote my first patch, and I need to know whether I missed something or not. I haven't used C for a really long time, so sickbags on standby, and if you notice something really stupid don't hesitate to call me an asshole (according to Simon Phipps that proves we are a healthy op

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Robert Haas writes: > On Sat, Dec 11, 2010 at 1:20 PM, Tom Lane wrote: >> I'm not really thinking about crash recovery, but replication slaves. >> Omitting to create the tablespace location directories on slaves >> doesn't seem far-fetched at all.  Of course, it's likely that >> the slave server

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

On Sat, Dec 11, 2010 at 1:20 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, Dec 11, 2010 at 10:56 AM, Tom Lane wrote: >>> OK.  Is there any value in doing mkdir -p in WAL-recovery execution of >>> CREATE TABLESPACE but not regular execution? > >> I don't think so.  If someone creates a dir

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Robert Haas writes: > On Sat, Dec 11, 2010 at 10:56 AM, Tom Lane wrote: >> OK.  Is there any value in doing mkdir -p in WAL-recovery execution of >> CREATE TABLESPACE but not regular execution? > I don't think so. If someone creates a directory that is not fsync'd, > and then creates a subdirec

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

On Sat, Dec 11, 2010 at 10:56 AM, Tom Lane wrote: > Stephen Frost writes: >> * Robert Haas (robertmh...@gmail.com) wrote: >>> On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane wrote: Anybody have a problem with adopting this behavior? > >>> Seems a bit surprising. > >> Yeahh..  I'm not really sure

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

Magnus Hagander writes: > On Sat, Dec 11, 2010 at 18:46, Tom Lane wrote: >> I think we can just #define the other cases as zeroes.  I'm not sure why >> you think that's an issue for open --- the privileges don't exist. > Hmm. I was/am worried about any case that specifies *just* one of the > per

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

On Sat, Dec 11, 2010 at 18:46, Tom Lane wrote: > Magnus Hagander writes: >> On Sat, Dec 11, 2010 at 17:55, Tom Lane wrote: >>> 1. How did all those pre-existing references to S_IRXWU compile? > >> Yeah, that's weird. IIRC (I stopped looking for the moment, need a >> step back) some of them were

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

Magnus Hagander writes: > On Sat, Dec 11, 2010 at 17:55, Tom Lane wrote: >> 1. How did all those pre-existing references to S_IRXWU compile? > Yeah, that's weird. IIRC (I stopped looking for the moment, need a > step back) some of them were protected by #ifndef WIN32, but not all > of them.. Th

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

Magnus Hagander writes: > On Sat, Dec 11, 2010 at 17:55, Tom Lane wrote: >> 2. Why didn't the previously hard-wired constants passed to chmod >> and umask fail on Windows?  The M$ documentation I can find at the >> moment suggests that *only* _S_IREAD and _S_IWRITE bits are allowed >> in the inpu

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

On Sat, Dec 11, 2010 at 17:55, Tom Lane wrote: > Magnus Hagander writes: >> On Sat, Dec 11, 2010 at 17:38, Tom Lane wrote: >>> No, it isn't.  There's an apparently-useless definition of _S_IRWXU >>> there, but no S_IRWXU. > >> Hmm. You're right, of course. > >> A search on my windows box finds t

Re: [HACKERS] proposal: auxiliary functions for record type

2010/12/11 Florian Pflug : > On Dec11, 2010, at 16:03 , Pavel Stehule wrote: >> 2010/12/11 Florian Pflug : >>> On Dec11, 2010, at 06:20 , Pavel Stehule wrote: I wrote a few functions for record type - record_expand, record_get_fields, record_get_field, record_set_fields. >>> >>> Just FYI,

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

Magnus Hagander writes: > On Sat, Dec 11, 2010 at 17:38, Tom Lane wrote: >> No, it isn't.  There's an apparently-useless definition of _S_IRWXU >> there, but no S_IRWXU. > Hmm. You're right, of course. > A search on my windows box finds the text string S_IRWXU in the > following "*.h" files acr

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

On Sat, Dec 11, 2010 at 17:38, Tom Lane wrote: > Magnus Hagander writes: >> On Sat, Dec 11, 2010 at 17:23, Tom Lane wrote: >>> I think the reason it's not failing is that it includes . > >> S_IRWXU is defined in port/win32.h... > > No, it isn't.  There's an apparently-useless definition of _S_IR

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

Magnus Hagander writes: > On Sat, Dec 11, 2010 at 17:23, Tom Lane wrote: >> I think the reason it's not failing is that it includes . > S_IRWXU is defined in port/win32.h... No, it isn't. There's an apparently-useless definition of _S_IRWXU there, but no S_IRWXU. regar

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

On Sat, Dec 11, 2010 at 17:23, Tom Lane wrote: > Magnus Hagander writes: >> On Sat, Dec 11, 2010 at 17:13, Tom Lane wrote: >>> Ah, I have a theory: . > >> Nope, not there. I can't find S_IWGRP in any of the files. > > Well, I notice that copydir.c compiled before, and still compiles after, > des

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

Magnus Hagander writes: > On Sat, Dec 11, 2010 at 17:13, Tom Lane wrote: >> Ah, I have a theory: . > Nope, not there. I can't find S_IWGRP in any of the files. Well, I notice that copydir.c compiled before, and still compiles after, despite this change: - if (mkdir(todir, S_IRUSR | S_IWUSR |

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

On Sat, Dec 11, 2010 at 17:13, Tom Lane wrote: > I wrote: >> Magnus Hagander writes: >>> This broke the buildfarm on Windows, and I'm not sure of the best way to >>> fix it. > >> Hm, those symbols are already in use elsewhere in the code; I would >> assume it's just a matter of missing #includes

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

I wrote: > Magnus Hagander writes: >> This broke the buildfarm on Windows, and I'm not sure of the best way to fix >> it. > Hm, those symbols are already in use elsewhere in the code; I would > assume it's just a matter of missing #includes in these particular > files. Where does Windows define

Re: [HACKERS] create tablespace fails silently, or succeeds improperly

Stephen Frost writes: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Fri, Dec 10, 2010 at 10:33 PM, Tom Lane wrote: >>> Anybody have a problem with adopting this behavior? >> Seems a bit surprising. > Yeahh.. I'm not really sure about mkdir -p type actions from a SQL > command. Not enti

Re: [HACKERS] proposal: auxiliary functions for record type

Hey Pavel, Everything looks fine, but I propose you to add record_set_field just for convenience and as opposite of record_get_field. 2010/12/11 Pavel Stehule > Hello > > I wrote a few functions for record type - record_expand, > record_get_fields, record_get_field, record_set_fields. > > A usa

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

Magnus Hagander writes: > This broke the buildfarm on Windows, and I'm not sure of the best way to fix > it. > We currently define read and write permissions in port/win32.h > specifically for windows. A quick-fix to just add these new ones as > aliases won't work, because they are used in both o

Re: [HACKERS] proposal: auxiliary functions for record type

On Dec11, 2010, at 16:03 , Pavel Stehule wrote: > 2010/12/11 Florian Pflug : >> On Dec11, 2010, at 06:20 , Pavel Stehule wrote: >>> I wrote a few functions for record type - record_expand, >>> record_get_fields, record_get_field, record_set_fields. >> >> Just FYI, I've created something similar a

Re: [HACKERS] proposal: auxiliary functions for record type

2010/12/11 Florian Pflug : > On Dec11, 2010, at 06:20 , Pavel Stehule wrote: >> I wrote a few functions for record type - record_expand, >> record_get_fields, record_get_field, record_set_fields. > > Just FYI, I've created something similar a while ago. The code can be found at > https://github.com

Re: [HACKERS] libpq changes for synchronous replication

On Mon, Dec 6, 2010 at 12:54 AM, Fujii Masao wrote: > On Mon, Dec 6, 2010 at 3:07 AM, Greg Smith wrote: >> The one time this year top-posting seems appropriate...this patch seems >> stalled waiting for some sort of response to the concerns Alvaro raised >> here. > > Sorry for the delay. I didn't

Re: [HACKERS] PS display and standby query conflict

On Thu, 2010-12-09 at 22:13 +0900, Fujii Masao wrote: > When I created the conflict between recovery and many read-only > transactions in the standby server for test purpose, I found that the > keyword "waiting" disappeared from PS display for just a moment > even though the conflict had not been

Re: [HACKERS] proposal: auxiliary functions for record type

On Dec11, 2010, at 06:20 , Pavel Stehule wrote: > I wrote a few functions for record type - record_expand, > record_get_fields, record_get_field, record_set_fields. Just FYI, I've created something similar a while ago. The code can be found at https://github.com/fgp/pg_record_inspect The main dif

Re: [HACKERS] Final(?) proposal for wal_sync_method changes

On Wed, Dec 8, 2010 at 15:40, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Dec 8, 2010 at 02:07, Tom Lane wrote: >>> [ win32.h says ] >>> #define fsync(fd) _commit(fd) > >>> What this means is that switching to a simple preference order >>> "fdatasync, then fsync" will result in choosing

[HACKERS] Re: [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

This broke the buildfarm on Windows, and I'm not sure of the best way to fix it. We currently define read and write permissions in port/win32.h specifically for windows. A quick-fix to just add these new ones as aliases won't work, because they are used in both open and umask calls. Since umask()

Re: [HACKERS] Anyone for SSDs?

> You can believe whatever you want, that doesn't make it true. completely agree. Like yours, Its just my point of view, not the reality. I agree with most points here, but I wondering how many good ideas are killed with the thought: "this will be a performance killer with so many random access, l

Re: [HACKERS] Anyone for SSDs?

On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote: > On 12/10/10 5:06 PM, Daniel Loureiro wrote: > > An quicksort method in > > sequential disk its just awful to be thinking in a non SSD world, but > > its possible in an SSD. > > So, code it. Shouldn't be hard to write a demo comparison. I d