Re: [HACKERS] Re: [HACKERS] Patch für MAP_HUGETLB for mmap() shared memory

Hi, On 2013-06-28 23:03:22 -0400, Bruce Momjian wrote: > Did we decide against specifying huge pages in Postgres? I don't think so. We need somebody to make some last modifications to the patch though and Christian doesn't seem to have the time atm. I think the bigger memory (size of the per pro

[HACKERS] [PATCH] big test separation POC

Dear hackers, Per various discussion about the potential impact of Robins non regression tests, here is a poc patch to separate big tests from others. "paralle_schedule" holds usual tests, "big_schedule" holds big tests. The makefile derives serial_schedule, parallel_big_schedule and serial

Re: [HACKERS] New regression test time

Josh Berkus escribió: > Hackers, > > Per discussion on these tests, I ran "make check" against 9.4 head, > applied all of the regression tests other than DISCARD. > > Time for 3 "make check" runs without new tests: 65.9s > > Time for 3 "make check runs with new tests: 71.7s > > So that's an inc

Re: [HACKERS] New regression test time

How did you evaluate that coverage increased "greatly"? I am not generally against these tests but I'd be surprised if the overall test coverage improved noticeably by this. Which makes 10% runtime overhead pretty hefty if the goal is to actually achieve a high coverage. I was relying on Robin

Re: [HACKERS] [GENERAL] pg_upgrade -u

On 6/28/13 9:43 PM, Bruce Momjian wrote: > On Fri, Jun 28, 2013 at 09:15:31PM -0400, Peter Eisentraut wrote: >> On 6/28/13 6:06 PM, Bruce Momjian wrote: >>> On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote: On 5/28/13 10:55 PM, Bruce Momjian wrote: > Wow, I never realized o

Re: [HACKERS] Re: [HACKERS] Patch für MAP_HUGETLB for mmap() shared memory

Did we decide against specifying huge pages in Postgres? --- On Tue, Oct 30, 2012 at 09:16:07PM +0100, Christian Kruse wrote: > Hey, > > ok, I think I implemented all of the changes you requested. All but > the ia64 depende

Re: [HACKERS] "pg_ctl promote" exit status

On Mon, Jan 28, 2013 at 09:46:32AM -0500, Peter Eisentraut wrote: > On 1/26/13 4:44 PM, Aaron W. Swenson wrote: > > You are right. Had I read a little further down, it seems that the > > exit status should actually be 7. > > 7 is OK for "not running", but what should we use when the server is not

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Thu, 2013-06-27 at 15:59 +0200, Andres Freund wrote: > Maybe the trick is to add a recovery.conf option to make postgres replay > to the first restartpoint and then shutdown. At that point you can be > sure there aren't any torn pages anymore (bugs aside). > In fact that sounds like a rather use

[HACKERS] Outputting UTC offset with to_char()

On Sun, Oct 21, 2012 at 05:40:40PM -0400, Andrew Dunstan wrote: > > I'm not sure if this has come up before. > > A client was just finding difficulties because to_char() doesn't > support formatting the timezone part of a timestamptz numerically > (i.e. as +-hhmm) instead of using a timezone name

Re: [HACKERS] [GENERAL] pg_upgrade -u

Peter Eisentraut writes: > On 6/28/13 6:06 PM, Bruce Momjian wrote: >> On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote: >>> pg_upgrade should somehow be able to find out by itself what the >>> superuser of the old cluster was. >> Uh, any idea how to do that? > select rolname fro

Re: [HACKERS] New regression test time

* Josh Berkus (j...@agliodbs.com) wrote: > So that's an increase of about 10% in test runtime (or 2 seconds per run > on my laptop), in order to greatly improve regression test coverage. > I'd say that splitting the tests is not warranted, and that we should go > ahead with these tests on their tes

Re: [HACKERS] [GENERAL] pg_upgrade -u

On Fri, Jun 28, 2013 at 09:15:31PM -0400, Peter Eisentraut wrote: > On 6/28/13 6:06 PM, Bruce Momjian wrote: > > On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote: > >> On 5/28/13 10:55 PM, Bruce Momjian wrote: > >>> Wow, I never realized other tools used -U for user, instead of -u.

Re: [HACKERS] Add more regression tests for CREATE OPERATOR

On 27 June 2013 09:00, Robert Haas wrote: > On Wed, Jun 26, 2013 at 3:29 AM, Szymon Guz wrote: > > OK, so I think this patch can be committed, I will change the status. > > We have a convention that roles created by the regression tests needs > to have "regress" or something of the sort in the n

Re: [HACKERS] [GENERAL] pg_upgrade -u

On 6/28/13 6:06 PM, Bruce Momjian wrote: > On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote: >> On 5/28/13 10:55 PM, Bruce Momjian wrote: >>> Wow, I never realized other tools used -U for user, instead of -u. >>> Should I change pg_upgrade to use -U for 9.4? I can keep supporting

Re: [HACKERS] COPY and Volatile default expressions

On 24 June 2013 10:21, Kohei KaiGai wrote: > Hi Simon, > > I checked this patch. One thing I could comment on is, do you think it is > a good > idea to have oid of exception function list on > contain_volatile_functions_walker()? > > The walker function is static thus here is no impact for other

Re: [HACKERS] Minor inheritance/check bug: Inconsistent behavior

On Sat, Jan 26, 2013 at 11:31:49AM +0530, Amit Kapila wrote: > On Friday, January 25, 2013 8:36 PM Bruce Momjian wrote: > > On Fri, Sep 14, 2012 at 02:04:51PM +, Amit kapila wrote: > > > On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote: > > > > > > On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapil

Re: [HACKERS] [NOVICE] index refuses to build

On Sun, Aug 26, 2012 at 09:47:01AM -0400, Bruce Momjian wrote: > On Thu, Dec 29, 2011 at 10:40:19PM -0500, Tom Lane wrote: > > Merlin Moncure writes: > > > On Thu, Dec 29, 2011 at 5:10 PM, Jean-Yves F. Barbier <12u...@gmail.com> > > > wrote: > > >> CREATE INDEX tst1m_name_lu_ix ON tst1m(unaccent(

Re: [HACKERS] [GENERAL] pg_upgrade -u

On Thu, May 30, 2013 at 08:42:21AM -0400, Ray Stell wrote: > > On May 29, 2013, at 11:07 AM, Bruce Momjian wrote: > > > On Wed, May 29, 2013 at 08:59:42AM -0400, Ray Stell wrote: > >>> [ moved to hacker ] The question is whether hard-wiring these > >>> helps more than it hurts, and which ones shoul

[HACKERS] psql and pset without any arguments

Hi, I was looking at psql 8.3 documention about \pset options and saw that there was the following note : "Note: It is an error to call \pset without any arguments. In the future this case might show the current status of all printing options." I looked backward and forward to find that this

Re: backend hangs at immediate shutdown (Re: [HACKERS] Back-branch update releases coming in a couple weeks)

On Fri, Jun 28, 2013 at 6:00 PM, Alvaro Herrera wrote: > MauMau escribió: > > Hi, > >> I did this. Please find attached the revised patch. I modified >> HandleChildCrash(). I tested the immediate shutdown, and the child >> cleanup succeeded. > > Thanks, committed. > > There are two matters pend

Re: [HACKERS] [GENERAL] pg_upgrade -u

On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote: > On 5/28/13 10:55 PM, Bruce Momjian wrote: > > Wow, I never realized other tools used -U for user, instead of -u. > > Should I change pg_upgrade to use -U for 9.4? I can keep supporting -u > > as an undocumented option. > > It se

Re: [HACKERS] New regression test time

On 2013-06-28 14:46:10 -0700, Josh Berkus wrote: > > > How did you evaluate that coverage increased "greatly"? I am not > > generally against these tests but I'd be surprised if the overall test > > coverage improved noticeably by this. Which makes 10% runtime overhead > > pretty hefty if the goal

Re: [HACKERS] [GENERAL] pg_upgrade -u

On Tue, May 28, 2013 at 09:08:03PM -0700, Joshua D. Drake wrote: > > On 05/28/2013 07:55 PM, Bruce Momjian wrote: > > >>Perhaps just documenting the behavior is all that is needed, but -U is > >>everywhere and I think that's a good thing. > > > >[ moved to hacker ] > > > >Wow, I never realized ot

Re: backend hangs at immediate shutdown (Re: [HACKERS] Back-branch update releases coming in a couple weeks)

MauMau escribió: Hi, > I did this. Please find attached the revised patch. I modified > HandleChildCrash(). I tested the immediate shutdown, and the child > cleanup succeeded. Thanks, committed. There are two matters pending here: 1. do we want postmaster to exit immediately after sending t

Re: [HACKERS] New regression test time

> How did you evaluate that coverage increased "greatly"? I am not > generally against these tests but I'd be surprised if the overall test > coverage improved noticeably by this. Which makes 10% runtime overhead > pretty hefty if the goal is to actually achieve a high coverage. I was relying on

Re: [HACKERS] New regression test time

On 2013-06-28 14:01:23 -0700, Josh Berkus wrote: > Per discussion on these tests, I ran "make check" against 9.4 head, > applied all of the regression tests other than DISCARD. > > Time for 3 "make check" runs without new tests: 65.9s > > Time for 3 "make check runs with new tests: 71.7s > > So

Re: [HACKERS] Add some regression tests for SEQUENCE

On 06/28/2013 02:15 PM, Robins Tharakan wrote: > Seems like thats because of a recent (15th May 2013) patch > (b14206862278347a379f2bb72d92d16fb9dcea45) that changed the error message > that is printed. Its just one line of difference actually. > > Let me know if this is otherwise good to go. > I'

Re: [HACKERS] Add some regression tests for SEQUENCE

On 06/28/2013 02:15 PM, Robins Tharakan wrote: > Seems like thats because of a recent (15th May 2013) patch > (b14206862278347a379f2bb72d92d16fb9dcea45) that changed the error message > that is printed. Its just one line of difference actually. > > Let me know if this is otherwise good to go. > I'

Re: [HACKERS] Add some regression tests for SEQUENCE

Seems like thats because of a recent (15th May 2013) patch (b14206862278347a379f2bb72d92d16fb9dcea45) that changed the error message that is printed. Its just one line of difference actually. Let me know if this is otherwise good to go. I'll checkout the latest revision and submit this patch again

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

I've fixed the problems you mentioned (see attached) - sorry, I was a bit careless with the docs. > + null_values = (Bitmapset *) WinGetPartitionLocalMemory( > + winobj, > + BITMAPSET_SIZE(words_needed)); > + Assert(null_valu

[HACKERS] New regression test time

Hackers, Per discussion on these tests, I ran "make check" against 9.4 head, applied all of the regression tests other than DISCARD. Time for 3 "make check" runs without new tests: 65.9s Time for 3 "make check runs with new tests: 71.7s So that's an increase of about 10% in test runtime (or 2 s

Re: [HACKERS] Add more regression tests for dbcommands

Hi Andres, Just an aside, your point about CONNECTION LIMIT was something that just didn't come to my mind and is probably a good way to test ALTER DATABASE with CONNECTION LIMIT. Its just that that actually wasn't what I was testing there. That 'CONNECTION LIMIT' test was coupled with CREATE DAT

Re: [HACKERS] Add some regression tests for SEQUENCE

On 05/07/2013 03:40 PM, Robins Tharakan wrote: > Hi, > > Have provided an updated patch as per Fabien's recent response on > Commitfest site. > Any and all feedback is appreciated. The updated patch is giving a FAILURE for me: parallel group (19 tests): limit temp plancache conversion rowtypes

Re: [HACKERS] PostgreSQL 9.3 latest dev snapshot

On 06/28/2013 06:51 PM, Alvaro Herrera wrote: > Magnus Hagander escribió: > >> However, if oyu're looking for a snapshot, please use the one on the >> ftpsite. Generating those snapshots on the git server is slow and >> expensive... > > Maybe we should redirect those gitweb snapshot URLs to the F

Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

On Fri, Jun 28, 2013 at 5:14 PM, Steve Singer wrote: > On 06/27/2013 05:04 AM, Szymon Guz wrote: >> >> On 27 June 2013 05:21, Steve Singer > > wrote: >> >> On 06/26/2013 04:47 PM, Szymon Guz wrote: >> >> >> >> >> >> >> Hi Steve, >> thanks for the changes. >> >> You'r

Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

On 28 June 2013 22:14, Steve Singer wrote: > > I think the value is more important than the name, I want to the tests to > make sure that the conversion is actually converting properly. With your > method of getting the class name without the module we can have both. > > The attached patch shoul

Re: FILTER for aggregates [was Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division]

On 21 June 2013 06:16, David Fetter wrote: > Please find attached a patch which allows subqueries in the FILTER > clause and adds regression testing for same. > This needs re-basing/merging following Robert's recent commit to make OVER unreserved. Regards, Dean -- Sent via pgsql-hackers maili

Re: [HACKERS] [PATCH] Fix conversion for Decimal arguments in plpython functions

On 06/27/2013 05:04 AM, Szymon Guz wrote: On 27 June 2013 05:21, Steve Singer > wrote: On 06/26/2013 04:47 PM, Szymon Guz wrote: Hi Steve, thanks for the changes. You're idea about common code for decimal and cdecimal is good, however not good enough. I lik

Re: [HACKERS] Add more regression tests for ASYNC

On 06/28/2013 12:42 PM, Josh Berkus wrote: > On 05/13/2013 05:37 PM, Robins Tharakan wrote: >> Hi, >> >> Patch to add more regression tests to ASYNC (/src/backend/commands/async). >> Take code-coverage from 39% to 75%. > > This isn't applying for me anymore due to changes in the > parallel_schedul

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 2013-06-28 12:26:52 -0400, Tom Lane wrote: > Robert Haas writes: > > On the other hand, I can't entirely shake the feeling that adding the > > information into WAL would be more reliable. > > That feeling has been nagging at me too. I can't demonstrate that > there's a problem when an ALTER T

Re: [HACKERS] Add more regression tests for ASYNC

On 05/13/2013 05:37 PM, Robins Tharakan wrote: > Hi, > > Patch to add more regression tests to ASYNC (/src/backend/commands/async). > Take code-coverage from 39% to 75%. This isn't applying for me anymore due to changes in the parallel_schedule file. Where did you mean this to execute in the seq

Re: [HACKERS] GIN improvements part2: fast scan

On Tue, Jun 25, 2013 at 2:20 AM, Alexander Korotkov wrote: > 4. If we do go with a new function, I'd like to just call it "consistent" >> (or consistent2 or something, to keep it separate form the old consistent >> function), and pass it a tri-state input for each search term. It might not >> be a

Re: [HACKERS] [9.3 CF 1] 2 Weeks In & The problem with Performance Patches

On Fri, Jun 28, 2013 at 4:16 PM, Josh Berkus wrote: > (2) ideas on how we can speed up/parallelize performance testing efforts > are extremely welcome. An official perf-test script in GIT, even if it only tests general pg-bench-like performance, that can take two builds and compare them, like un

Re: [HACKERS] [9.3 CF 1] 2 Weeks In & The problem with Performance Patches

On 2013-06-28 12:16:09 -0700, Josh Berkus wrote: > - Remove PD_ALL_VISIBLE** I think this is primarily delayed because people don't agree it's a good idea. > - Use posix_fallocate to build (new) WAL files** I don't think this needs much further testing. We should just remove the enable/disable k

[HACKERS] [9.3 CF 1] 2 Weeks In & The problem with Performance Patches

Folks, We are starting the 3rd week of the commitfest tommorrow, and here's the update on status. In the last week, we are at the following status levels: - 40 patches still Need Review, including 11 which have no reviewer assigned. - 23 patches are Waiting on Author, most of them be

Re: [HACKERS] fallocate / posix_fallocate for new WAL file creation (etc...)

On 06/20/2013 07:19 PM, Jeff Davis wrote: > On Sun, 2013-06-16 at 23:53 -0500, Jon Nelson wrote: >> Please find attached v5 of the patch, with the above correction in place. >> The only change from the v4 patch is wrapping the if >> (wal_use_fallocate) block in an #ifdef USE_POSIX_FALLOCATE. >> Tha

Re: [HACKERS] Documentation/help for materialized and recursive views

On Fri, Jun 28, 2013 at 01:34:17PM -0400, Peter Eisentraut wrote: > On 6/28/13 10:49 AM, Alvaro Herrera wrote: > > Magnus Hagander escribió: > > > >> They are already crosslinked under "see also". But that doesn't > >> really help the guy doing "\h CREATE VIEW" in psql, which was the > >> case whe

Re: [HACKERS] [RFC] Minmax indexes

>> On Fri, Jun 28, 2013 at 2:18 PM, Jim Nasby wrote: >>> If we add a dirty flag it would probably be wise to allow for more >>> than one >>> value so we can do a clock-sweep. That would allow for detecting a range >>> that is getting dirtied repeatedly and not bother to try and >>> re-summarize i

Re: [HACKERS] Documentation/help for materialized and recursive views

Peter Eisentraut escribió: > On 6/28/13 10:49 AM, Alvaro Herrera wrote: > > Magnus Hagander escribió: > > > >> They are already crosslinked under "see also". But that doesn't really > >> help the guy doing "\h CREATE VIEW" in psql, which was the case where > >> it was brought to my attention. > >

Re: [HACKERS] [RFC] Minmax indexes

On 6/28/13 12:26 PM, Claudio Freire wrote: On Fri, Jun 28, 2013 at 2:18 PM, Jim Nasby wrote: On 6/17/13 3:38 PM, Josh Berkus wrote: Why? Why can't we just update the affected pages in the index? The page range has to be scanned in order to find out the min/max values for the indexed colu

Re: [HACKERS] Documentation/help for materialized and recursive views

On 6/28/13 10:49 AM, Alvaro Herrera wrote: > Magnus Hagander escribió: > >> They are already crosslinked under "see also". But that doesn't really >> help the guy doing "\h CREATE VIEW" in psql, which was the case where >> it was brought to my attention. > > Maybe \h should somehow display the "s

Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division

On 6/28/13 11:30 AM, Robert Haas wrote: > On Fri, Jun 28, 2013 at 10:31 AM, Tom Lane wrote: >> David Fetter writes: >>> Please find attached the latest patch. >> >> I remain of the opinion that this is simply a bad idea. It is unlike >> our habits for constructing other types of nodes, and makes

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On Fri, Jun 28, 2013 at 12:29 PM, Nicholas White wrote: >> This patch will need to be rebased over those changes > > See attached - Thanks. But I see a few issues... + [respect nulls]|[ignore nulls] You fixed one of these but missed the other. default are evaluated wit

Re: [HACKERS] [RFC] Minmax indexes

On Fri, Jun 28, 2013 at 2:18 PM, Jim Nasby wrote: > On 6/17/13 3:38 PM, Josh Berkus wrote: Why? Why can't we just update the affected pages in the index? >>> >>> > >>> >The page range has to be scanned in order to find out the min/max values >>> >for the indexed columns on the range; an

Re: [HACKERS] [RFC] Minmax indexes

On 6/17/13 3:38 PM, Josh Berkus wrote: Why? Why can't we just update the affected pages in the index? > >The page range has to be scanned in order to find out the min/max values >for the indexed columns on the range; and then, with these data, update >the index. Seems like you could incrementa

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 28 June 2013 17:10, Robert Haas wrote: > > But to tell the truth, I'm mostly exercised about the non-unique > > syscache. I think that's simply a *bad* idea. > > +1. > > I don't think the extra index on pg_class is going to hurt that much, > even if we create it always, as long as we use a p

Re: [HACKERS] PostgreSQL 9.3 latest dev snapshot

Magnus Hagander escribió: > However, if oyu're looking for a snapshot, please use the one on the > ftpsite. Generating those snapshots on the git server is slow and > expensive... Maybe we should redirect those gitweb snapshot URLs to the FTP site? -- Álvaro Herrerahttp://www.2n

Re: [HACKERS] ALTER TABLE ... ALTER CONSTRAINT

Simon Riggs escribió: > Looks like that really is a deficiency in my tool chain on OSX, rather than > some bug/user error. Even at the very latest, very shiny version. > > Latest versions of gcc trap the error, so I'll have to investigate an > alternative. Funnily enough, on Debian Wheezy with g

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

> This patch will need to be rebased over those changes See attached - lead-lag-ignore-nulls.patch Description: Binary data -- 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] changeset generation v5-01 - Patches & git tree

Robert Haas writes: > On the other hand, I can't entirely shake the feeling that adding the > information into WAL would be more reliable. That feeling has been nagging at me too. I can't demonstrate that there's a problem when an ALTER TABLE is in process of rewriting a table into a new relfile

Re: [HACKERS] Move unused buffers to freelist

On Fri, Jun 28, 2013 at 12:10 PM, Greg Smith wrote: > This refactoring idea will make that hard to keep around. I think this is > OK though. Switching to a latch based design should eliminate the > bgwriter_delay, which means you won't have this worst case of a 200ms stall > while heavy activity

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On Fri, Jun 28, 2013 at 11:56 AM, Tom Lane wrote: > Robert Haas writes: >> I'm just talking out of my rear end here because I don't know what the >> real numbers are, but it's far from obvious to me that there's any >> free lunch here. That having been said, just because indexing >> relfilenode

Re: [HACKERS] Move unused buffers to freelist

On 6/28/13 8:50 AM, Robert Haas wrote: On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila wrote: 4. Separate processes for writing dirty buffers and moving buffers to freelist I think this part might be best pushed to a separate patch, although I agree we probably need it. This might be necessar

Re: [HACKERS] ALTER TABLE ... ALTER CONSTRAINT

On 24 June 2013 22:17, Simon Riggs wrote: > On 24 June 2013 21:42, Jeff Janes wrote: > >> On Sun, Jun 23, 2013 at 8:58 PM, Abhijit Menon-Sen >> wrote: >> >>> At 2013-06-08 21:45:24 +0100, si...@2ndquadrant.com wrote: >>> > >>> > ALTER TABLE foo >>> >ALTER CONSTRAINT fktable_fk_fkey DEFERRED

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

On Fri, Jun 28, 2013 at 05:21:29PM +0200, Pavel Stehule wrote: > 2013/6/28 Noah Misch : > > Okay. I failed to note the first time through that while the patch uses the > > same option names for RAISE and GET STACKED DIAGNOSTICS, the existing option > > lists for those commands differ: > > > > --RA

Re: [HACKERS] PostgreSQL 9.3 latest dev snapshot

On 06/27/2013 12:22 PM, Magnus Hagander wrote: > On Tue, Jun 25, 2013 at 3:31 PM, Michael Paquier > wrote: >> >> On 2013/06/25, at 22:23, Fujii Masao wrote: >> >>> On Tue, Jun 25, 2013 at 6:33 PM, Michael Paquier >>> wrote: On Tue, Jun 25, 2013 at 5:33 PM, Misa Simic wrote: > Hi, >

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

Robert Haas writes: > I'm just talking out of my rear end here because I don't know what the > real numbers are, but it's far from obvious to me that there's any > free lunch here. That having been said, just because indexing > relfilenode or adding relfilenodes to WAL records is expensive doesn'

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On Fri, Jun 28, 2013 at 11:41 AM, Alvaro Herrera wrote: > Robert Haas escribió: >> On Thu, Jun 27, 2013 at 8:52 PM, Nicholas White wrote: > >> The documentation you've added reads kind of funny to me: >> >> + [respect nulls]|[ignore nulls] >> >> Wouldn't we normally write that as [ [ RESP

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

Alvaro Herrera escribió: > An INSERT wal record is: > > typedef struct xl_heap_insert > { > xl_heaptid target; /* inserted tuple id */ > boolall_visible_cleared;/* PD_ALL_VISIBLE was cleared */ > /* xl_heap_header & TUPLE DATA FOLLOWS AT END

Re: [HACKERS] Review: query result history in psql

Hello I am not sure, this interface is really user friendly there is not possible "searching" in history, and not every query push to history some interesting content. It require: * simply decision if content should be stored in history or not, * simply remove last entry (table) of history * qu

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

Robert Haas escribió: > On Thu, Jun 27, 2013 at 8:52 PM, Nicholas White wrote: > The documentation you've added reads kind of funny to me: > > + [respect nulls]|[ignore nulls] > > Wouldn't we normally write that as [ [ RESPECT | IGNORE ] NULLS ] ? I think it should be [ { RESPECT | IGN

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

Robert Haas escribió: > On Fri, Jun 28, 2013 at 10:49 AM, Tom Lane wrote: > > Robert's idea sounds fairly reasonable to me; another 4 bytes per > > insert/update/delete WAL entry isn't that big a deal, ... > > How big a deal is it? This is a serious question, because I don't > know. Let's suppo

Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division

On Fri, Jun 28, 2013 at 10:31 AM, Tom Lane wrote: > David Fetter writes: >> Please find attached the latest patch. > > I remain of the opinion that this is simply a bad idea. It is unlike > our habits for constructing other types of nodes, and makes it harder > not easier to find all the places

Re: [HACKERS] Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls

On Thu, Jun 27, 2013 at 8:52 PM, Nicholas White wrote: >> The result of the current patch using lead > > Actually, I think I agree with you (and, FWIW, so does Oracle: > http://docs.oracle.com/cd/E11882_01/server.112/e25554/analysis.htm#autoId18). > I've refactored the window function's implementa

Re: [HACKERS] extensible external toast tuple support

On Fri, Jun 28, 2013 at 10:53 AM, Andres Freund wrote: >> Why does toast_insert_or_update() need to go through all the >> rigamarole in toast_datum_differs()? I would have thought that it >> could simply treat any external-indirect value as needing to be >> detoasted and retoasted, since the dest

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

2013/6/28 Noah Misch : > On Fri, Jun 28, 2013 at 03:31:00PM +0200, Pavel Stehule wrote: >> Hello >> >> 2013/6/28 Noah Misch : >> > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote: >> >> 2013/6/28 Noah Misch : >> >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote: >> >>

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On Fri, Jun 28, 2013 at 10:49 AM, Tom Lane wrote: > Robert's idea sounds fairly reasonable to me; another 4 bytes per > insert/update/delete WAL entry isn't that big a deal, ... How big a deal is it? This is a serious question, because I don't know. Let's suppose that the average size of an XLO

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

On Fri, Jun 28, 2013 at 03:31:00PM +0200, Pavel Stehule wrote: > Hello > > 2013/6/28 Noah Misch : > > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote: > >> 2013/6/28 Noah Misch : > >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote: > >> >> cleaned patch is in attachm

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 2013-06-28 10:49:26 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-06-28 08:41:46 -0400, Robert Haas wrote: > >> The alternative I previously proposed was to make the WAL records > >> carry the relation OID. There are a few problems with that: one is > >> that it's a waste of space

[HACKERS] Re: Department of Redundancy Department: makeNode(FuncCall) division

On Fri, Jun 28, 2013 at 10:31:16AM -0400, Tom Lane wrote: > David Fetter writes: > > Please find attached the latest patch. > > I remain of the opinion that this is simply a bad idea. It is unlike > our habits for constructing other types of nodes, and makes it harder > not easier to find all th

Re: [HACKERS] extensible external toast tuple support

On 2013-06-28 09:49:53 -0400, Robert Haas wrote: > On Fri, Jun 28, 2013 at 9:23 AM, Robert Haas wrote: > > On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund > > wrote: > >> Please find attached the next version of the extensible toast > >> support. There basically are two changes: > >> > >> * hand

Re: [HACKERS] Documentation/help for materialized and recursive views

On Fri, Jun 28, 2013 at 4:49 PM, Alvaro Herrera wrote: > Magnus Hagander escribió: > >> They are already crosslinked under "see also". But that doesn't really >> help the guy doing "\h CREATE VIEW" in psql, which was the case where >> it was brought to my attention. > > Maybe \h should somehow dis

Re: [HACKERS] Documentation/help for materialized and recursive views

Magnus Hagander escribió: > They are already crosslinked under "see also". But that doesn't really > help the guy doing "\h CREATE VIEW" in psql, which was the case where > it was brought to my attention. Maybe \h should somehow display the "see also" section? -- Álvaro Herrerah

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

Andres Freund writes: > On 2013-06-28 08:41:46 -0400, Robert Haas wrote: >> The alternative I previously proposed was to make the WAL records >> carry the relation OID. There are a few problems with that: one is >> that it's a waste of space when logical replication is turned off, and >> it might

Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division

On Fri, Jun 28, 2013 at 10:31:16AM -0400, Tom Lane wrote: > David Fetter writes: > > Please find attached the latest patch. > > I remain of the opinion that this is simply a bad idea. It is unlike > our habits for constructing other types of nodes, and makes it harder > not easier to find all th

Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division

David Fetter writes: > Please find attached the latest patch. I remain of the opinion that this is simply a bad idea. It is unlike our habits for constructing other types of nodes, and makes it harder not easier to find all the places that need to be updated when adding another field to FuncCall

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 6/28/13 8:46 AM, Andres Freund wrote: > I personally favor making catalog modifications a bit more more > expensive instead of increasing the WAL volume during routine > operations. I don't think index maintenance itself comes close to the > biggest cost for DDL we have atm. That makes sense to

Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division

On Tue, Jun 25, 2013 at 02:54:55PM +0530, Jeevan Chalke wrote: > On Tue, Jun 25, 2013 at 11:11 AM, Jeevan Chalke < > jeevan.cha...@enterprisedb.com> wrote: > > > Hi David, > > > > I hope this is the latest patch to review, right ? > > > > I am going to review it. > > > > I have gone through the di

Re: [HACKERS] extensible external toast tuple support

On Fri, Jun 28, 2013 at 9:23 AM, Robert Haas wrote: > On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund > wrote: >> Please find attached the next version of the extensible toast >> support. There basically are two changes: >> >> * handle indirect toast tuples properly in heap_tuple_fetch_attr >>

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

Hello 2013/6/28 Noah Misch : > On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote: >> 2013/6/28 Noah Misch : >> > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote: >> >> cleaned patch is in attachment >> > >> > Of the five options you're adding to GET STACKED DIAGNOSTICS, f

Re: [HACKERS] extensible external toast tuple support

On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund wrote: > Please find attached the next version of the extensible toast > support. There basically are two changes: > > * handle indirect toast tuples properly in heap_tuple_fetch_attr > and related places > * minor comment adjustments It looks to

Re: [HACKERS] proposal: enable new error fields in plpgsql (9.4)

On Fri, Jun 28, 2013 at 07:49:46AM +0200, Pavel Stehule wrote: > 2013/6/28 Noah Misch : > > On Tue, Jun 25, 2013 at 03:56:27PM +0200, Pavel Stehule wrote: > >> cleaned patch is in attachment > > > > Of the five options you're adding to GET STACKED DIAGNOSTICS, four of them > > appear in the SQL sta

Re: [HACKERS] Move unused buffers to freelist

On Fri, Jun 28, 2013 at 8:50 AM, Robert Haas wrote: > On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila wrote: >> Currently it wakes up based on bgwriterdelay config parameter which is by >> default 200ms, so you means we should >> think of waking up bgwriter based on allocations and number of elemen

Re: [HACKERS] Move unused buffers to freelist

On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila wrote: > Currently it wakes up based on bgwriterdelay config parameter which is by > default 200ms, so you means we should > think of waking up bgwriter based on allocations and number of elements left > in freelist? I think that's what Andres and I a

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 2013-06-27 21:52:03 -0700, Kevin Grittner wrote: > Tried that, too, and problem persists.  The log shows the last > commit on your branch as 022c2da1873de2fbc93ae524819932719ca41bdb. > I get the same failure, with primary key or unique index column > showing as 0 in results. I have run enough

Re: [HACKERS] Improvement of checkpoint IO scheduler for stable transaction responses

(2013/06/28 0:08), Robert Haas wrote: On Tue, Jun 25, 2013 at 4:28 PM, Heikki Linnakangas wrote: I'm pretty sure Greg Smith tried it the fixed-sleep thing before and it didn't work that well. I have also tried it and the resulting behavior was unimpressive. It makes checkpoints take a long tim

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On 2013-06-28 08:41:46 -0400, Robert Haas wrote: > On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund wrote: > > What that means is that for every heap record in the target database in > > the WAL we need to query pg_class to turn the relfilenode into a > > pg_class.oid. So, we can easily replace sysc

Re: [HACKERS] changeset generation v5-01 - Patches & git tree

On Fri, Jun 28, 2013 at 3:32 AM, Andres Freund wrote: > What that means is that for every heap record in the target database in > the WAL we need to query pg_class to turn the relfilenode into a > pg_class.oid. So, we can easily replace syscache.c with some custom > caching code, but I don't think

Re: [HACKERS] Group Commits Vs WAL Writes

> > Yep. To take a degenerate case, suppose that you had many small WAL > records, say 64 bytes each, so more than 100 per 8K block. If you > flush those one by one, you're going to rewrite that block 100 times. > If you flush them all at once, you write that block once. > > But even when the ran

Re: [HACKERS] Group Commits Vs WAL Writes

> > There is a spot on the disk to which the current WAL is destined to go. > That spot on the disk is not going to be under the write-head for (say) > another 6 milliseconds. > > Without commit_delay, I try to commit my record, but find that someone else > is already on the lock (and on the fsync

  1   2   >