Re: [HACKERS] opportunistic tuple freezing

On Sun, 2009-08-16 at 18:32 -0700, Jeff Davis wrote: > If VACUUM freezes one tuple on a page, it's likely that there are others > on the same page that are close to vacuum_freeze_min_age, but not quite. > Because the page is already dirty from freezing one tuple, it makes > sense to be more aggress

Re: [HACKERS] Split-up ECPG patches

On Sun, Aug 16, 2009 at 05:59:46PM +0200, Boszormenyi Zoltan wrote: > > What heppens if the sqlda is incompatible? > > Returns false? I wasn't talking about this one function but about the flow of the resulting program. How can it happen that sqlda is incompatible and what happens then? Michael

[HACKERS] Buffer usage in EXPLAIN and pg_stat_statements

1 UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2; | 26999 | 1929 UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2; | 25474 | 1 SELECT abalance FROM pgbench_accounts WHERE aid = $1;| 19950 | 0 (4 rows) Regards, --- ITAGA

Re: [HACKERS] hot standby - merged up to CVS HEAD

Robert Haas wrote: > I had some review comments > I was hoping to get responses to, in the section beginning with "A few > other comments based on a preliminary reading of this patch": > > http://archives.postgresql.org/pgsql-hackers/2009-07/msg00854.php Having read the patch now, here's a one is

Re: [HACKERS] Buffer usage in EXPLAIN and pg_stat_statements

2009/8/17 Itagaki Takahiro : > Here is a proposal to add buffer usage information to EXPLAIN and > contrib/pg_stat_statements. We can retrieve new values 'gets', > 'reads' and 'temp': > >    - gets  : total number of buffer pool access >    - reads : total number of data file access >    - temp  :

[HACKERS] memory free of constantly changed function

Hello Tom Lane, Tao Ma I saw the post with title "question about the _SPI_save_plan() and plan cache" discussing about memory free of dropped function. I am using dynamically created function to imitate dynamic compound statement in DB2. I use function_factory(t1 text, t2 text, t3 text), pasted b

Re: [HACKERS] hot standby - merged up to CVS HEAD

On Mon, Aug 17, 2009 at 4:19 AM, Heikki Linnakangas wrote: > Robert Haas wrote: >> I had some review comments >> I was hoping to get responses to, in the section beginning with "A few >> other comments based on a preliminary reading of this patch": >> >> http://archives.postgresql.org/pgsql-hackers

Re: [HACKERS] 8.5 development schedule

On Tue, Jun 30, 2009 at 1:33 AM, Peter Eisentraut wrote: > Now that 8.4.0 is out the door, development for 8.5devel will be opened any > day now.  But we haven't discussed the development timeline so far.  The core > team has several proposals: > > CommitFest      Alpha > Aug. 1          Sept. 1 >

[HACKERS] different plan when using partitions: stats for inherited tables in joins

following: http://www.mail-archive.com/pgsql-gene...@postgresql.org/msg135076.html I recreated the problem using a join between 2 tables: explain select nome1, dltbfpgpdch FROM cell_bsc_60_0610 as cell_bsc left outer join teststscell73_test_0610_1 as data on data.ne_id=cell_bsc.nome1 where data

Re: [HACKERS] 8.5 development schedule

On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote: > Now that the first CommitFest is over and done with, I think you forgot the part where you tell everyone that it is in fact done. I'm waiting on you before I get the alpha release rolling. -- Sent via pgsql-hackers mailing list (pgsql-hac

[HACKERS] Road to alpha1

Per http://wiki.postgresql.org/wiki/Alpha_release_process: * Commit fest manager declares commit fest closed: kind of done * Build farm status green or failures adequately explained: some breakage because of local configuration problems (mostly old flex), no serious problems * Naming: 8.5alpha1

Re: [HACKERS] Road to alpha1

On Mon, 2009-08-17 at 16:00 +0300, Peter Eisentraut wrote: > * Optional: Translation updates -- not this time Actually it might be easier for translators to start translating now, instead of starting 1 month before the release. I know, strings may change -- but they may always change. -- Devrim G

Re: [HACKERS] Road to alpha1

On Mon, 2009-08-17 at 16:11 +0300, Devrim GÜNDÜZ wrote: > On Mon, 2009-08-17 at 16:00 +0300, Peter Eisentraut wrote: > > * Optional: Translation updates -- not this time > > Actually it might be easier for translators to start translating now, > instead of starting 1 month before the release. I kn

Re: [HACKERS] 8.5 development schedule

On Mon, Aug 17, 2009 at 8:43 AM, Peter Eisentraut wrote: > On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote: >> Now that the first CommitFest is over and done with, > > I think you forgot the part where you tell everyone that it is in fact > done.  I'm waiting on you before I get the alpha rele

Re: [HACKERS] opportunistic tuple freezing

Peter Eisentraut writes: > The patch might make sense anyway, but I think it might not be such an > overwhelming winner in practice. As always with patches that are meant to improve performance, some experimental evidence would be a good thing. regards, tom lane -- Sent

Re: [HACKERS] contrib/pg_freespacemap

On Aug 8, 2009, at 2:55 PM, Josh Berkus wrote: On 8/8/09 10:50 AM, Alvaro Herrera wrote: Tom Lane wrote: Alvaro Herrera writes: Is there any reason we didn't move the pg_freespace function from contrib to core? Is there a reason we *should* move it? The current definition doesn't leave me

[HACKERS] CommitFest 2009-07: Remaining Patches Moved To CommitFest 2009-09

Per Peter's request to wrap this up, I have moved the last three patches to the next CommitFest. They are: Filtering dictionary support and unaccent dictionary plpythonu datatype conversion improvements query cancel issues in dblink All of these seem like they are pretty

Re: [HACKERS] [PATCH] plpythonu datatype conversion improvements

Peter Eisentraut writes: > The remaining problem is that the patch loses domain checking on the > return types, because some paths no longer go through the data type's > input function. I have marked these places as FIXME, and the regression > tests also contain a failing test case for this. For

Re: [HACKERS] freezing tuples ( was: Why is vacuum_freeze_min_age100m? )

Jeff Davis wrote: > There are two ways to do the threshold: > 1. Constant fraction of vacuum_freeze_min_age > 2. Extra GUC I appreciate that there may be room to improve this while protecting the forensic values; but there are already strategies for managing the day-to-day performance iss

Re: [HACKERS] [PATCH] plpythonu datatype conversion improvements

Tom Lane wrote: For the record, I think this entire patch is a bad idea. PLs should not be so much in bed with the internal representation of datatypes. I thought there was some suggestion in the past that we should move some in that direction. The discussion context was Theo Schlossn

Re: [HACKERS] [PATCH] plpythonu datatype conversion improvements

Andrew Dunstan writes: > Tom Lane wrote: >> For the record, I think this entire patch is a bad idea. PLs should not >> be so much in bed with the internal representation of datatypes. > I thought there was some suggestion in the past that we should move some > in that direction. There's been

Re: [HACKERS] CommitFest 2009-07: Remaining Patches Moved To CommitFest 2009-09

Robert Haas writes: > ... this > allows us to mark the current CommitFest as closed, which I have done. [ applause ] I think we owe Robert a vote of thanks for so energetically shepherding this commitfest. It seemed to me the fest went a lot faster, in relation to the number and size of patches

[HACKERS] Pl/perlu, DBD::Oracle and Sys:SigAction problem - crash of backend process

Greetings! I've encounter repeatable postgres crash. I developed set of pl/perlu functions to import data from oracle to postgres. there is one function that initializes session variables ($_SHARED) . Everything was very effective and fast but... when Oracle host disconnected plperlu function that

Re: [HACKERS] CommitFest 2009-07: Remaining Patches Moved To CommitFest 2009-09

On Mon, Aug 17, 2009 at 17:27, Tom Lane wrote: > Robert Haas writes: >> ... this >> allows us to mark the current CommitFest as closed, which I have done. > > [ applause ] > > I think we owe Robert a vote of thanks for so energetically shepherding > this commitfest. +1 (at least)! -- Magnus H

Re: [HACKERS] [PATCH] plpythonu datatype conversion improvements

Peter Eisentraut wrote: > I have reworked this patch a bit and extended the plpython test suite > around it. Current copy attached. I think the errcontext bits should be committed separately to get them out of the way (and to ensure that they get in, regardless of objections to other parts of th

Re: [HACKERS] Pl/perlu, DBD::Oracle and Sys:SigAction problem - crash of backend process

Tomasz Olszak wrote: Greetings! I've encounter repeatable postgres crash. I developed set of pl/perlu functions to import data from oracle to postgres. I should have thought modifying signal handlers in PLPerl was a straight recipe for disaster, even if the code puts them back or thinks i

Re: [HACKERS] CommitFest 2009-07: Remaining Patches Moved To CommitFest 2009-09

Tom Lane writes: > Robert Haas writes: >> ... this >> allows us to mark the current CommitFest as closed, which I have done. > > [ applause ] there's some weird trans-atlantic echoing here, Hats down to Robert CommitFest-mom Haas ;) -- dim -- Sent via pgsql-hackers mailing list (pgsql-hacker

Re: [HACKERS] CommitFest 2009-07: Remaining Patches Moved To CommitFest 2009-09

On Mon, Aug 17, 2009 at 11:27 AM, Tom Lane wrote: > Robert Haas writes: >> ... this >> allows us to mark the current CommitFest as closed, which I have done. > > [ applause ] > > I think we owe Robert a vote of thanks for so energetically shepherding > this commitfest.  It seemed to me the fest we

[HACKERS] Another try at reducing repeated detoast work for PostGIS

There was recently another go-round on the postgis-devel list about the same problem Mark Cave-Ayland complained about last year: http://archives.postgresql.org/pgsql-hackers/2008-06/msg00384.php Basically, what is happening is a nestloop join where the inner indexscan gets a comparison argument fr

Re: [HACKERS] Alpha 1 release notes

Peter, Attached is a new draft of the "release notes". What I've done in this version is added more subsections and arranged stuff into groups by funcitonality area. I think this makes the notes vastly easier to scan; having 25 items generically under "server" wasn't helpful at all to find featu

Re: [HACKERS] Pl/perlu, DBD::Oracle and Sys:SigAction problem - crashof backend process

Than you for your quick answer Adrew, I read some documentation about plperl etc. but didn't see ,,don't even think about it'' advice :). cheers Tomek Dnia 17 sierpnia 2009 18:07 Andrew Dunstan napisał(a): Tomasz Olszak wrote: > Greetings! > > I've encounter repeatable post

Re: [HACKERS] Road to alpha1

Peter Eisentraut escreveu: > On Mon, 2009-08-17 at 16:11 +0300, Devrim GÜNDÜZ wrote: >> On Mon, 2009-08-17 at 16:00 +0300, Peter Eisentraut wrote: >>> * Optional: Translation updates -- not this time >> Actually it might be easier for translators to start translating now, >> instead of starting 1 m

Re: [HACKERS] CommitFest 2009-07: Remaining Patches Moved To CommitFest 2009-09

On Mon, 2009-08-17 at 11:27 -0400, Tom Lane wrote: > I think we owe Robert a vote of thanks for so energetically shepherding > this commitfest. It seemed to me the fest went a lot faster, in > relation to the number and size of patches presented, than any of the > previous fests did. I think that

Re: [HACKERS] Another try at reducing repeated detoast work for PostGIS

On Mon, 2009-08-17 at 13:37 -0400, Tom Lane wrote: > Thinking about it again, it seems to me that a much narrower patch > could solve the specific forms of the problem that the PostGIS folk > are seeing. Instead of trying to have a general-purpose method of > preventing repeat de-toasting, we coul

Re: [HACKERS] Alpha 1 release notes

Josh Berkus writes: > Attached is a new draft of the "release notes". I went over this quickly, and attach an updated version. This is updated to current CVS HEAD, and wordsmithed a little bit, and I removed some things that didn't seem worth documenting. In particular, the introduction claims

Re: [HACKERS] Another try at reducing repeated detoast work for PostGIS

Jeff Davis writes: > On Mon, 2009-08-17 at 13:37 -0400, Tom Lane wrote: >> Thinking about it again, it seems to me that a much narrower patch >> could solve the specific forms of the problem that the PostGIS folk >> are seeing. Instead of trying to have a general-purpose method of >> preventing r

Re: [HACKERS] Road to alpha1

Euler Taveira de Oliveira writes: > Peter Eisentraut escreveu: >> Possibly, but there aren't going to be any new translations within the >> next two days. We may want to reconsider this for the next alpha. >> > IMHO, it's too much work for an alpha cycle. Why not encourage it _only_ after > the

Re: [HACKERS] Alpha 1 release notes

On 8/17/09 11:51 AM, Tom Lane wrote: > I went over this quickly, and attach an updated version. This is > updated to current CVS HEAD, and wordsmithed a little bit, and I removed > some things that didn't seem worth documenting. In particular, the > introduction claims that back-patched bug fixes

Re: [HACKERS] Another try at reducing repeated detoast work for PostGIS

On Mon, 2009-08-17 at 14:54 -0400, Tom Lane wrote: > > If so, is it possible that two similar plans for the same query might > > perform differently due to repeated de-toasting? > > Hard to answer that one. What's "similar"? My only concern is that it's a somewhat hidden optimization (not seen i

Re: [HACKERS] Alpha 1 release notes

All, New version, incorporating Tom's changes and some additional reordering. Particularly, we seemed to vacillate between present and past tense for the patch descriptions. I have changed all to past tense. Also, should we be adding patch author names to these notes? -- Josh Berkus PostgreS

Re: [HACKERS] Alpha 1 release notes

Josh Berkus writes: > On 8/17/09 11:51 AM, Tom Lane wrote: >> I went over this quickly, and attach an updated version. This is >> updated to current CVS HEAD, and wordsmithed a little bit, and I removed >> some things that didn't seem worth documenting. In particular, the >> introduction claims

Re: [HACKERS] Alpha 1 release notes

Josh Berkus writes: > Particularly, we seemed to vacillate between present and past tense for > the patch descriptions. I have changed all to past tense. Actually, present tense is our general style for the release notes, and I had carefully made them all present tense ;-). It doesn't appear to

Re: [HACKERS] Another try at reducing repeated detoast work for PostGIS

On Mon, Aug 17, 2009 at 2:54 PM, Tom Lane wrote: > Jeff Davis writes: >> On Mon, 2009-08-17 at 13:37 -0400, Tom Lane wrote: >>> Thinking about it again, it seems to me that a much narrower patch >>> could solve the specific forms of the problem that the PostGIS folk >>> are seeing.  Instead of try

Re: [HACKERS] Alpha 1 release notes

Tom, > Actually, present tense is our general style for the release notes, and > I had carefully made them all present tense ;-). It doesn't appear to > me that you've been consistent about it here anyway. OK, switching back to present tense then. Does anyone else see anything missing? Also, d

Re: [HACKERS] Another try at reducing repeated detoast work for PostGIS

Robert Haas writes: > On Mon, Aug 17, 2009 at 2:54 PM, Tom Lane wrote: >> Well, it solves the case people have actually complained about (twice >> now).  I originally attempted to solve a larger set of cases, but it's >> not clear there's enough value in that. > How related is this issue? > http

Re: [HACKERS] Alpha 1 release notes

Josh Berkus writes: > Also, does the ADD/DROP COLUMN plpgsql patch fix any cases other than > RETURNS QUERY? I can't tell from the patch. Yes, I believe it does, but hadn't bothered to work up any test cases. The places it touched in plpgsql are * returning a single composite value

Re: [HACKERS] Alpha 1 release notes

On mån, 2009-08-17 at 10:39 -0700, Josh Berkus wrote: > Peter, > > Attached is a new draft of the "release notes". > > What I've done in this version is added more subsections and arranged > stuff into groups by funcitonality area. I think this makes the notes > vastly easier to scan; having 25

Re: [HACKERS] Alpha 1 release notes

Peter, Since I'd need to install haskell on my system before installing pandoc, I've attached my "final" edit of the RST file so that I don't hold things up. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com .. -*- mode: rst -*- = Release 8.5alpha1 = Overv

Re: [HACKERS] 8.5 development schedule

On mån, 2009-08-17 at 10:22 -0400, Robert Haas wrote: > On Mon, Aug 17, 2009 at 8:43 AM, Peter Eisentraut wrote: > > On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote: > >> Now that the first CommitFest is over and done with, > > > > I think you forgot the part where you tell everyone that it is

Re: [HACKERS] 8.5 development schedule

Peter Eisentraut wrote: > Well, in the past the commit fest manager has usually written an > email, "The commit fest is now closed". With the new commitfest software, as the last patch is moved out of "pending" and the commitfest moved to "closed" status -- I can practically hear the bang of

[HACKERS] explain root element for auto-explain

The attached tiny patch sets the root element for auto-explain XML output, so it looks something like this: http://www.postgresql.org/2009/explain";> Result 0.00 0.01 1 0 The JSON output looks like this: [ "Plan": { "Node

Re: [HACKERS] [PATCH] plpythonu datatype conversion improvements

On mån, 2009-08-17 at 10:42 -0400, Tom Lane wrote: > For the record, I think this entire patch is a bad idea. PLs should not > be so much in bed with the internal representation of datatypes. To > take just one example, this *will* break when/if we change text to carry > some internal locale indi

Re: [HACKERS] Alpha 1 release notes

On mån, 2009-08-17 at 14:29 -0700, Josh Berkus wrote: > Since I'd need to install haskell on my system before installing pandoc, > I've attached my "final" edit of the RST file so that I don't hold > things up. committed that -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

[HACKERS] PQgetlength vs. octet_length()

Hello everyone. Having a weird issue. I have a value inserted into a bytea column, which is about 137megs in size. If I use octet_length() to check the size of the column for this specific row I get this: TestDB=# SELECT octet_length(rawdata) FROM LargeData; octet_length -- 14372

Re: [HACKERS] explain root element for auto-explain

Andrew Dunstan writes: > The attached tiny patch sets the root element for auto-explain > XML output, so it looks something like this: This looks reasonable in itself, but it sort of begs the question on two other things: * what's the xmlns URL really going to be? * what's the element in reg

Re: [HACKERS] drop tablespace error: invalid argument

On Aug 16, 2009, at 8:25 PM, Tom Lane wrote: Jan Otto writes: ERROR: could not read directory "pg_tblspc/16464": Invalid argument STATEMENT: DROP TABLESPACE testspace; Hmm ... can't reproduce this here, not even on OSX. From the version number I suspect you are using unreleased Snow Leopar

Re: [HACKERS] [COMMITTERS] pgsql: Add release notes for 8.5alpha1

pet...@postgresql.org (Peter Eisentraut) writes: > Add release notes for 8.5alpha1 The bit about Windows shared memory is duplicated, which doubtless is a reflection of confusion about where to put it. We could add a section "Ports" and put that and the SuperH item in it, perhaps. Thoughts?

Re: [HACKERS] explain root element for auto-explain

Tom Lane wrote: Andrew Dunstan writes: The attached tiny patch sets the root element for auto-explain XML output, so it looks something like this: This looks reasonable in itself, but it sort of begs the question on two other things: * what's the xmlns URL really going to be?

Re: [HACKERS] explain root element for auto-explain

Andrew Dunstan wrote: Tom Lane wrote: * what's the xmlns URL really going to be? By convention it refers to a place where you publish the schema for the document type, but it is in fact completely arbitrary, and can refer to a non-existant resource - as long as it is unique - it's j

Re: [HACKERS] explain root element for auto-explain

Andrew Dunstan writes: > One thing I definitely think we should do is to put the namespace URL in > a header file. Think of it as being a bit like the catversion. > Hardcoding it in explain.c doesn't seem like a good idea. Well, it could at least be a #define, but what's the point of exposing i

Re: [HACKERS] explain root element for auto-explain

Tom Lane wrote: Andrew Dunstan writes: One thing I definitely think we should do is to put the namespace URL in a header file. Think of it as being a bit like the catversion. Hardcoding it in explain.c doesn't seem like a good idea. Well, it could at least be a #define, but what's

Re: [HACKERS] Road to alpha1

On Mon, 17 Aug 2009, Euler Taveira de Oliveira wrote: Peter Eisentraut escreveu: On Mon, 2009-08-17 at 16:11 +0300, Devrim G?ND?Z wrote: On Mon, 2009-08-17 at 16:00 +0300, Peter Eisentraut wrote: * Optional: Translation updates -- not this time Actually it might be easier for translators to

Re: [HACKERS] COPY speedup

I'm doing some more exploration with oprofile... I've got the glibc-debug package installed (on kubuntu), but oprofile doesn't seem to know about it. I wonder what part of glibc gets 60% of the run time... do I have to set a magic option in the postgres config ? samples %image nam

Re: [HACKERS] Road to alpha1

Tom Lane escreveu: > Euler Taveira de Oliveira writes: >> Peter Eisentraut escreveu: >>> Possibly, but there aren't going to be any new translations within the >>> next two days. We may want to reconsider this for the next alpha. >>> >> IMHO, it's too much work for an alpha cycle. Why not encoura

Re: [HACKERS] [PATCH] plpythonu datatype conversion improvements

2009/8/18 Peter Eisentraut : > On mån, 2009-08-17 at 10:42 -0400, Tom Lane wrote: >> For the record, I think this entire patch is a bad idea.  PLs should not >> be so much in bed with the internal representation of datatypes.  To >> take just one example, this *will* break when/if we change text to