Re: [HACKERS] Reduce pinning in btree indexes

> "Kyotaro" == Kyotaro HORIGUCHI writes: >> You might want to try running the same test, but after patching >> ExecSupportsMarkRestore to return false for index scans. This will >> cause the planner to insert a Materialize node to handle the >> mark/restore. Kyotaro> Mmm? The patch bt-n

Re: [HACKERS] Merge compact/non compact commits, make aborts dynamically sized

On Wed, Feb 25, 2015 at 8:10 PM, Andres Freund wrote: > On 2015-02-24 20:51:42 +0200, Heikki Linnakangas wrote: >> On 02/20/2015 05:21 PM, Andres Freund wrote: >> >There's one bit that I'm not so sure about though: To avoid duplication >> >I've added Parse(Commit/Abort)Record(), but unfortunately

Re: [HACKERS] Reduce pinning in btree indexes

Hi, At Fri, 27 Feb 2015 05:56:18 +, Andrew Gierth wrote in <874mq77vuu@news-spur.riddles.org.uk> > > "Kyotaro" == Kyotaro HORIGUCHI writes: > > Kyotaro> ammarkpos/amrestrpos are called in merge joins. By the steps > Kyotaro> shown below, I had 1M times of markpos and no restorepo

Re: [HACKERS] New CF app deployment

On 02/26/2015 01:59 PM, Michael Paquier wrote: > On Thu, Feb 26, 2015 at 9:15 PM, Asif Naeem wrote: >> This thread seems relevant, Please guide me to how can access older CF pages >>> The MSVC portion of this fix got completely lost in the void: >>> https://commitfest.postgresql.org/action/patch_v

Re: [HACKERS] Providing catalog view to pg_hba.conf file - Patch submission

On Sat, Feb 7, 2015 at 8:26 PM, Pavel Stehule wrote: > Hi > > I am sending a review of this patch. Thanks for the review. sorry for the delay. > 4. Regress tests > > test rules... FAILED -- missing info about new view Thanks. Corrected. > My objections: > > 1. data type f

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 3 February 2015 at 22:23, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hi, I had a look on this patch. Although I haven't understood > whole the stuff and all of the related things, I will comment as > possible. > > Great, thank you for taking the time to look and review the pa

Re: [HACKERS] Reduce pinning in btree indexes

> "Kyotaro" == Kyotaro HORIGUCHI writes: Kyotaro> ammarkpos/amrestrpos are called in merge joins. By the steps Kyotaro> shown below, I had 1M times of markpos and no restorepos for Kyotaro> 1M result rows, and had 500k times of markpos and the same Kyotaro> number of times of restorepos f

Re: [HACKERS] Reduce pinning in btree indexes

Hello, I measured the performance of this patch considering markpos/restorepos. The loss seems to be up to about 10% unfortunately. At Thu, 26 Feb 2015 17:49:23 + (UTC), Kevin Grittner wrote in <440831854.629116.1424972963735.javamail.ya...@mail.yahoo.com> > Heikki Linnakangas wrote:> On 02

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

> "Tom" == Tom Lane writes: Tom> We've discussed doing $SUBJECT off and on for nearly ten years, Tom> the oldest thread I could find about it being here: Tom> http://www.postgresql.org/message-id/flat/1186435268.16321.37.ca...@dell.linuxdev.us.dell.com Tom> It's come up again every time

[HACKERS] Add CINE for ALTER TABLE ... ADD COLUMN

Hi all, This simple patch add CINE for ALTER TABLE ... ADD COLUMN. So now we can: ALTER TABLE foo ADD COLUMN IF NOT EXISTS c1 integer; and/or ... ALTER TABLE foo ADD COLUMN IF NOT EXISTS c1 integer, ADD COLUMN c2 integer; Regards, -- Fabrízio de Royes Mello Consultoria/Coaching

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Fri, Feb 27, 2015 at 8:01 AM, Michael Paquier wrote: > On Fri, Feb 27, 2015 at 6:54 AM, Rahila Syed wrote: >>>Even this patch doesn't work fine. The standby emit the following >>>error messages. >> >> Yes this bug remains unsolved. I am still working on resolving this. >> >> Following chunk ID

Re: [HACKERS] Odd behavior of updatable security barrier views on foreign tables

On 2015/02/26 11:38, Stephen Frost wrote: I've pushed an update for this to master and 9.4 and improved the comments and the commit message as discussed. Would be great if you could test and let me know if you run into any issues! OK, thanks! Best regards, Etsuro Fujita -- Sent via pgsql-ha

Re: [HACKERS] MemoryContext reset/delete callbacks

Andres Freund writes: > It's a bit sad to push AllocSetContextData onto four cachelines from the > current three... That stuff is hot. But I don't really see a way around > it right now. And it seems like it'd give us more amunition to improve > things than the small loss of speed it implies. Meh

Re: [HACKERS] GSoC idea - Simulated annealing to search for query plans

On 02/26/2015 05:50 PM, Fabrízio de Royes Mello wrote: > > On Thu, Feb 26, 2015 at 10:27 PM, Andres Freund > wrote: >> >> On 2015-02-26 20:23:33 -0500, Tom Lane wrote: >> > Josh Berkus mailto:j...@agliodbs.com>> writes: >> > > On 02/26/2015 01:59 PM, Grzegorz Parka

Re: [HACKERS] logical column ordering

On 27/02/15 14:08, David Steele wrote: [...] I agree with Jim's comments. I've generally followed column ordering that goes something like: 1) primary key 2) foreign keys 3) flags 4) other programmatic data fields (type, order, etc.) 5) non-programmatic data fields (name, description, etc.) Th

Re: [HACKERS] Partitioning WIP patch

On 27-02-2015 AM 03:01, Jim Nasby wrote: > On 2/26/15 3:09 AM, Amit Langote wrote: >> Unless I'm missing something again, isn't allowing partitions to have >> heterogeneous rowtypes a problem in the long run? I'm afraid I'm >> confused as to your stand regarding inheritance vs. new partitioning. To

Re: [HACKERS] GSoC idea - Simulated annealing to search for query plans

On Thu, Feb 26, 2015 at 10:27 PM, Andres Freund wrote: > > On 2015-02-26 20:23:33 -0500, Tom Lane wrote: > > Josh Berkus writes: > > > On 02/26/2015 01:59 PM, Grzegorz Parka wrote: > > >> I'm interested in one of old TODO items related to the optimizer - > > >> 'Consider compressed annealing to s

Re: [HACKERS] contrib/fuzzystrmatch/dmetaphone.c license

On Thu, Feb 26, 2015 at 8:56 AM, Stephen Frost wrote: > * Jim Nasby (jim.na...@bluetreble.com) wrote: >> On 2/25/15 4:10 PM, Andrew Dunstan wrote: >> > >> >On 02/25/2015 11:59 AM, Joe Conway wrote: >> >>> >> >>>It's largely because of such uncertainties that I have been advised >> >>>in the past (

Re: [HACKERS] GSoC idea - Simulated annealing to search for query plans

On 2015-02-26 20:23:33 -0500, Tom Lane wrote: > Josh Berkus writes: > > On 02/26/2015 01:59 PM, Grzegorz Parka wrote: > >> I'm interested in one of old TODO items related to the optimizer - > >> 'Consider compressed annealing to search for query plans'. > > > You might look at the earlier attempt

Re: [HACKERS] GSoC idea - Simulated annealing to search for query plans

Josh Berkus writes: > On 02/26/2015 01:59 PM, Grzegorz Parka wrote: >> I'm interested in one of old TODO items related to the optimizer - >> 'Consider compressed annealing to search for query plans'. > You might look at the earlier attempt to make the GEQO replacement > "pluggable". That project

Re: [HACKERS] GSoC idea - Simulated annealing to search for query plans

On 02/26/2015 01:59 PM, Grzegorz Parka wrote: > Dear Hackers, > > I'm Grzegorz Parka, BSc Engineer of Technical Physics and student of > Computer Science at WUT, Poland. Last year I've been a bit into > evolutionary algorithms and during my research I found out about GEQO in > Postgres. I also fou

Re: [HACKERS] logical column ordering

On 2/26/15 1:49 PM, Jim Nasby wrote: > On 2/23/15 5:09 PM, Tomas Vondra wrote: >> Over the time I've heard various use cases for this patch, but in most >> cases it was quite speculative. If you have an idea where this might be >> useful, can you explain it here, or maybe point me to a place where

Re: [HACKERS] MemoryContext reset/delete callbacks

On 2015-02-27 01:54:27 +0100, Andres Freund wrote: > On 2015-02-26 19:28:50 -0500, Tom Lane wrote: > > /* > > *** typedef struct MemoryContextData > > *** 59,72 > > MemoryContext firstchild; /* head of linked list of children */ > > MemoryContext nextchild;/

Re: [HACKERS] Partitioning WIP patch

On Fri, Feb 27, 2015 at 3:24 AM, Andres Freund wrote: > On 2015-02-26 12:15:17 +0900, Amit Langote wrote: >> On 26-02-2015 AM 05:15, Josh Berkus wrote: >> > On 02/24/2015 12:13 AM, Amit Langote wrote: >> >> Here is an experimental patch that attempts to implement this. > >> > I would love to have

Re: [HACKERS] MemoryContext reset/delete callbacks

Hi, On 2015-02-26 19:28:50 -0500, Tom Lane wrote: > We discussed this idea a couple weeks ago. Hm, didn't follow that discussion. > The core of it is that when a memory context is being deleted, you > might want something extra to happen beyond just pfree'ing everything > in the context. I've c

Re: [HACKERS] Partitioning WIP patch

On 27-02-2015 AM 03:18, Josh Berkus wrote: > On 02/25/2015 07:15 PM, Amit Langote wrote: >> I'm not quite sure what would qualify as baked enough for 9.5 though we >> can surely try to reach some consensus on various implementation aspects >> and perhaps even get it ready in time for 9.5. > > Well

[HACKERS] MemoryContext reset/delete callbacks

We discussed this idea a couple weeks ago. The core of it is that when a memory context is being deleted, you might want something extra to happen beyond just pfree'ing everything in the context. I'm thinking in particular that this might provide a nice solution to the problem we discussed earlie

Re: [HACKERS] Partitioning WIP patch

On 27-02-2015 AM 03:24, Andres Freund wrote: > On 2015-02-26 12:15:17 +0900, Amit Langote wrote: >> On 26-02-2015 AM 05:15, Josh Berkus wrote: >>> I would love to have it for 9.5, but I guess the >>> patch isn't nearly baked enough for that? > >> I'm not quite sure what would qualify as baked enou

Re: [HACKERS] Precedence of standard comparison operators

On 2015-02-26 20:13:34 +, Simon Riggs wrote: > On 26 February 2015 at 15:56, Tom Lane wrote: > > >> I think the way to do this is to have a pluggable parser, so users can > >> choose 1) old parser, 2) new, better parser, 3) any other parser they > >> fancy that they maintain to ensure applica

Re: [HACKERS] logical column ordering

On 2/26/15 4:34 PM, Andres Freund wrote: On 2015-02-26 16:16:54 -0600, Jim Nasby wrote: On 2/26/15 4:01 PM, Alvaro Herrera wrote: The reason for doing it this way is that changing the underlying architecture is really hard, without having to bear an endless hackers bike shed discussion about th

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

On 2015-02-26 18:05:46 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2015-02-26 17:45:26 -0500, Tom Lane wrote: > > If the changes breaks some code it's likely actually a good thing: > > Because, as you say, using MemoryContextReset() will likely be the wrong > > thing, and they'll want to

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

Andres Freund writes: > On 2015-02-26 17:45:26 -0500, Tom Lane wrote: >> With all due respect, that's utterly wrong. I have looked at every single >> MemoryContextReset call in the codebase, and as far as I can see the >> *only* one that is in an error path is elog.c:336, which I'm quite certain

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Fri, Feb 27, 2015 at 6:54 AM, Rahila Syed wrote: > Hello, > >>Even this patch doesn't work fine. The standby emit the following >>error messages. > > Yes this bug remains unsolved. I am still working on resolving this. > > Following chunk IDs have been added in the attached patch as suggested >

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

Andres Freund writes: > I'd really not even be surprised if a committer backpatches a > MemoryContextReset() addition, not realizing it behaves differently in > the back branches. As far as that goes, the only consequence would be a possible memory leak in the back branches; it would not be a rea

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

Andres Freund writes: > ... Without a compiler erroring out people won't > notice that suddenly MemoryContextReset deletes much more; leading to > possibly hard to find errors. BTW, so far as *data* is concerned, the existing call deletes all data in the child contexts already. The only not-alre

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

On 2015-02-26 17:45:26 -0500, Tom Lane wrote: > Andres Freund writes: > Or are you arguing for an alternative proposal in which we remove > MemoryContextReset (or at least rename it to something new) and thereby > intentionally break all code that uses MemoryContextReset? Yes, that I am. After a

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

Andres Freund writes: > On 2015-02-26 17:01:53 -0500, Tom Lane wrote: >> We've discussed doing $SUBJECT off and on for nearly ten years, >> the oldest thread I could find about it being here: >> http://www.postgresql.org/message-id/flat/1186435268.16321.37.ca...@dell.linuxdev.us.dell.com >> It's c

Re: [HACKERS] Precedence of standard comparison operators

On 2/26/15 4:09 PM, Tom Lane wrote: Andres Freund writes: On February 26, 2015 10:29:18 PM CET, Peter Eisentraut wrote: My suggestion was to treat this like the standard_conforming_string change. That is, warn for many years before changing. I don't think scs is a good example to follow.

Re: [HACKERS] logical column ordering

Tomas Vondra wrote: > Over the time I've heard various use cases for this patch, but in most > cases it was quite speculative. If you have an idea where this might be > useful, can you explain it here, or maybe point me to a place where it's > described? One use case is to be able to suppress d

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

On 2015-02-26 23:31:16 +0100, Andres Freund wrote: > Without a compiler erroring out people won't notice that suddenly > MemoryContextReset deletes much more; leading to possibly hard to find > errors. Context resets frequently are in error paths, and those won't > necessarily be hit when running w

Re: [HACKERS] logical column ordering

Jim Nasby writes: > On 2/26/15 4:01 PM, Alvaro Herrera wrote: >> Josh Berkus wrote: >>> Oh, I didn't realize there weren't commands to change the LCO. Without >>> at least SQL syntax for LCO, I don't see why we'd take it; this sounds >>> more like a WIP patch. >> The reason for doing it this way

Re: [HACKERS] logical column ordering

On 2015-02-26 16:16:54 -0600, Jim Nasby wrote: > On 2/26/15 4:01 PM, Alvaro Herrera wrote: > >The reason for doing it this way is that changing the underlying > >architecture is really hard, without having to bear an endless hackers > >bike shed discussion about the best userland syntax to use. It

Re: [HACKERS] json_populate_record issue - TupleDesc reference leak

Andrew Dunstan writes: > This doesn't look quite right. Shouldn't we unconditionally release the > Tupledesc before the returns at lines 2118 and 2127, just as we do at > the bottom of the function at line 2285? I think Pavel's patch is probably OK as-is, because the tupdesc returned by get_cal

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

Hi, On 2015-02-26 17:01:53 -0500, Tom Lane wrote: > We've discussed doing $SUBJECT off and on for nearly ten years, > the oldest thread I could find about it being here: > http://www.postgresql.org/message-id/flat/1186435268.16321.37.ca...@dell.linuxdev.us.dell.com > It's come up again every time

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

Alvaro Herrera writes: > Tom Lane wrote: >> Thoughts? Any objections to pushing this? > Is there any reason at all to keep > MemoryContextResetButPreserveChildren()? Since your patch doesn't add > any callers, it seems pretty likely that there's none anywhere. The only reason to keep it is to

Re: [HACKERS] logical column ordering

On 2/26/15 4:01 PM, Alvaro Herrera wrote: Josh Berkus wrote: On 02/26/2015 01:54 PM, Alvaro Herrera wrote: This patch decouples these three things so that they can changed freely -- but provides no user interface to do so. I think that trying to only decouple the thing we currently have in two

Re: [HACKERS] Precedence of standard comparison operators

Andres Freund writes: > On February 26, 2015 10:29:18 PM CET, Peter Eisentraut > wrote: >> My suggestion was to treat this like the standard_conforming_string >> change. That is, warn for many years before changing. > I don't think scs is a good example to follow. Yeah. For one thing, there

Re: [HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

Tom Lane wrote: > Thoughts? Any objections to pushing this? Is there any reason at all to keep MemoryContextResetButPreserveChildren()? Since your patch doesn't add any callers, it seems pretty likely that there's none anywhere. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ Pos

[HACKERS] Renaming MemoryContextResetAndDeleteChildren to MemoryContextReset

We've discussed doing $SUBJECT off and on for nearly ten years, the oldest thread I could find about it being here: http://www.postgresql.org/message-id/flat/1186435268.16321.37.ca...@dell.linuxdev.us.dell.com It's come up again every time we found another leak of dead child contexts, which happene

Re: [HACKERS] Idea: GSoC - Query Rewrite with Materialized Views

Thank you for your answers. I would be very interested in tracking the staleness of the MV. You see, I work in a research group in database tuning, and we have implemented some solutions to take advantage of MV's and speed up queries. The query rewrite feature would be extremely desirable for us. D

Re: [HACKERS] logical column ordering

Josh Berkus wrote: > On 02/26/2015 01:54 PM, Alvaro Herrera wrote: > > This patch decouples these three things so that they > > can changed freely -- but provides no user interface to do so. I think > > that trying to only decouple the thing we currently have in two pieces, > > and then have a sub

[HACKERS] GSoC idea - Simulated annealing to search for query plans

Dear Hackers, I'm Grzegorz Parka, BSc Engineer of Technical Physics and student of Computer Science at WUT, Poland. Last year I've been a bit into evolutionary algorithms and during my research I found out about GEQO in Postgres. I also found out that there are plans to try a different attempt to

Re: [HACKERS] logical column ordering

On 02/26/2015 01:54 PM, Alvaro Herrera wrote: > This patch decouples these three things so that they > can changed freely -- but provides no user interface to do so. I think > that trying to only decouple the thing we currently have in two pieces, > and then have a subsequent patch to decouple aga

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

Hello, >Even this patch doesn't work fine. The standby emit the following >error messages. Yes this bug remains unsolved. I am still working on resolving this. Following chunk IDs have been added in the attached patch as suggested upthread. +#define XLR_CHUNK_BLOCK_REFERENCE 0x10 +#define XLR_C

Re: [HACKERS] logical column ordering

Josh Berkus wrote: > On 02/26/2015 10:49 AM, Jim Nasby wrote: > > The other reason for this patch (which it maybe doesn't support > > anymore?) is to allow Postgres to use an optimal physical ordering of > > fields on a page to reduce space wasted on alignment, as well as taking > > nullability an

Re: [HACKERS] Precedence of standard comparison operators

On February 26, 2015 10:29:18 PM CET, Peter Eisentraut wrote: >On 2/25/15 5:15 PM, Simon Riggs wrote: >> Having a warn_if_screwed parameter that we disable by default won't >> help much because if you are affected you can't change that >situation. >> There are too many applications to test all of

Re: [HACKERS] Precedence of standard comparison operators

On 2/25/15 5:15 PM, Simon Riggs wrote: > Having a warn_if_screwed parameter that we disable by default won't > help much because if you are affected you can't change that situation. > There are too many applications to test all of them and not all > applications can be edited, even if they were tes

Re: [HACKERS] json_populate_record issue - TupleDesc reference leak

On 02/23/2015 12:56 PM, Pavel Stehule wrote: by the way - this feature is undocumented - I though so only value used as type holder is not used. Should be documented better, - if I understand - it is base stone for implementation #= hstore operator some nice example postgres=# select json_

Re: [HACKERS] Precedence of standard comparison operators

Simon Riggs writes: > On 26 February 2015 at 15:56, Tom Lane wrote: >> I don't find that particularly attractive either. It seems quite unlikely >> to me that anyone would actually use such a hook; replacing the whole >> parser would be essentially unmaintainable. Nobody uses the hooks you >> m

Re: [HACKERS] Precedence of standard comparison operators

On 26 February 2015 at 15:56, Tom Lane wrote: >> I think the way to do this is to have a pluggable parser, so users can >> choose 1) old parser, 2) new, better parser, 3) any other parser they >> fancy that they maintain to ensure application compatibility. We've >> got a pluggable executor and o

Re: [HACKERS] plpgsql versus domains

Andres Freund writes: > On 2015-02-26 13:53:18 -0500, Tom Lane wrote: >> I thought that's what I was proposing in point #1. > Sure, but my second point was to avoid duplicating that information into > ->fcinfo and such and instead reference the typecache entry from > there. So that if the typecac

Re: [HACKERS] logical column ordering

On 02/26/2015 10:49 AM, Jim Nasby wrote: > On 2/23/15 5:09 PM, Tomas Vondra wrote: >> Over the time I've heard various use cases for this patch, but in most >> cases it was quite speculative. If you have an idea where this might be >> useful, can you explain it here, or maybe point me to a place wh

Re: [HACKERS] plpgsql versus domains

2015-02-26 19:53 GMT+01:00 Tom Lane : > Andres Freund writes: > > On 2015-02-26 12:31:46 -0500, Tom Lane wrote: > >> 2. In plpgsql, explicitly model a domain type as being its base type > >> plus some constraints --- that is, stop depending on domain_in() to > >> enforce the constraints, and do i

Re: [HACKERS] plpgsql versus domains

On 2015-02-26 13:53:18 -0500, Tom Lane wrote: > Andres Freund writes: > > Hm. A bit sad to open code that in plpgsql instead of making it > > available more generally. > > The actual checking wouldn't be open-coded, it would come from > domain_check() (or possibly a modified version of that). It

Re: [HACKERS] plpgsql versus domains

Andres Freund writes: > On 2015-02-26 12:31:46 -0500, Tom Lane wrote: >> 2. In plpgsql, explicitly model a domain type as being its base type >> plus some constraints --- that is, stop depending on domain_in() to >> enforce the constraints, and do it ourselves. This would mean that >> the FmgrInf

Re: [HACKERS] logical column ordering

On 2/23/15 5:09 PM, Tomas Vondra wrote: Over the time I've heard various use cases for this patch, but in most cases it was quite speculative. If you have an idea where this might be useful, can you explain it here, or maybe point me to a place where it's described? For better or worse, table s

Re: [HACKERS] plpgsql versus domains

Hi, On 2015-02-26 12:31:46 -0500, Tom Lane wrote: > It's really slow, because any assignment to a domain variable goes through > the slow double-I/O-conversion path in exec_cast_value, even if no actual > work is needed. Hm, that's surely not nice for some types. Doing syscache lookups every time

Re: [HACKERS] How to create virtual indexes on postgres

On 2/26/15 6:17 AM, Sreerama Manoj wrote: But, it runs with Postgres 9.1 version...But I use 9.4..I think I cant use that. Or as an alternative Is there any provision in postgres to know use(Increase in Performance) of an index before creating that index. No. It might not be too hard to port t

Re: [HACKERS] Partitioning WIP patch

On 2015-02-26 12:15:17 +0900, Amit Langote wrote: > On 26-02-2015 AM 05:15, Josh Berkus wrote: > > On 02/24/2015 12:13 AM, Amit Langote wrote: > >> Here is an experimental patch that attempts to implement this. > > I would love to have it for 9.5, but I guess the > > patch isn't nearly baked enoug

Re: [HACKERS] Partitioning WIP patch

On 02/25/2015 07:15 PM, Amit Langote wrote: > On 26-02-2015 AM 05:15, Josh Berkus wrote: >> On 02/24/2015 12:13 AM, Amit Langote wrote: >>> Here is an experimental patch that attempts to implement this. >> >> This looks awesome. > > Thanks! > >> I would love to have it for 9.5, but I guess the >

Re: [HACKERS] Partitioning WIP patch

On 2/26/15 3:22 AM, Andres Freund wrote: On 2015-02-26 02:20:21 -0600, Jim Nasby wrote: The reason I'd like to do this with partitioning vs plain inheritance is presumably as we build out partitioning we'll get very useful things like the ability to have FKs to properly partitioned tables. Inser

Re: [HACKERS] mogrify and indent features for jsonb

On 02/26/2015 07:25 AM, Thom Brown wrote: > Yeah, I think that may be problematic. I agree with Josh that there's > probably no sane mix of operators for this, as I would expect your > example to replace "d": ["aa","bb","cc","dd"] with "d": ["ee"] rather > than append to it. Hmm... unless we used

Re: [HACKERS] Partitioning WIP patch

On 2/26/15 3:09 AM, Amit Langote wrote: Yes. If it helps, the exact use-case I have in mind is using list-based >partitioning + additional columns in some/all children (different >between children). For example, if you need to track different types of >customer payment methods, you'd have a payme

Re: [HACKERS] plpgsql versus domains

Hi 2015-02-26 18:31 GMT+01:00 Tom Lane : > At the behest of Salesforce, I've been looking into improving plpgsql's > handling of variables of domain types, which is currently pretty awful. > It's really slow, because any assignment to a domain variable goes through > the slow double-I/O-conversio

Re: [HACKERS] Reduce pinning in btree indexes

Heikki Linnakangas wrote:> On 02/15/2015 02:19 AM, Kevin Grittner wrote: >> Interestingly, the btree README points out that using the old TID >> with a new tuple poses no hazard for a scan using an MVCC snapshot, >> because the new tuple would not be visible to a snapshot created >> that long ago

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 26.2.2015 18:34, Tom Lane wrote: > Tomas Vondra writes: >> FWIW this apparently happens because the code only expect that >> EquivalenceMembers only contain Var, but in this particular case that's >> not the case - it contains RelabelType (because oprcode is regproc, and >> needs to be relabele

Re: [HACKERS] Precedence of standard comparison operators

Andrew Dunstan writes: > On 02/26/2015 10:56 AM, Tom Lane wrote: >> I find this argument to be unhelpful, because it could be made in exactly >> the same words against any non-backwards-compatible change whatsoever. >> Nonetheless, we do make non-backwards-compatible changes all the time. > That'

Re: [HACKERS] Performance improvement for joins where outer side is unique

Tomas Vondra writes: > FWIW this apparently happens because the code only expect that > EquivalenceMembers only contain Var, but in this particular case that's > not the case - it contains RelabelType (because oprcode is regproc, and > needs to be relabeled to oid). If it thinks an EquivalenceMem

[HACKERS] plpgsql versus domains

At the behest of Salesforce, I've been looking into improving plpgsql's handling of variables of domain types, which is currently pretty awful. It's really slow, because any assignment to a domain variable goes through the slow double-I/O-conversion path in exec_cast_value, even if no actual work i

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On 2/26/15 1:00 AM, Fujii Masao wrote: > On Thu, Feb 26, 2015 at 1:40 PM, Alvaro Herrera >> Clearly if you log only DROP TABLE, and then the malicious user hides >> one such call inside a function that executes the drop (which is called >> via a SELECT top-level SQL), you're not going to be happy.

Re: [HACKERS] Precedence of standard comparison operators

On 02/26/2015 10:56 AM, Tom Lane wrote: Simon Riggs writes: On 20 February 2015 at 20:44, Tom Lane wrote: Well, assuming that we're satisfied with just having a way to warn when the behavior changed (and not, in particular, a switch that can select old or new behavior) I'm in favour of your

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 26.2.2015 01:15, Tomas Vondra wrote: > > I'm not quite sure why, but eclassjoin_is_unique_join() never actually > jumps into this part (line ~400): > > if (relvar != NULL && candidaterelvar != NULL) > { > ... > index_vars = lappend(index_vars, candidaterelvar); >

Re: [HACKERS] Precedence of standard comparison operators

Simon Riggs writes: > On 20 February 2015 at 20:44, Tom Lane wrote: >> Well, assuming that we're satisfied with just having a way to warn >> when the behavior changed (and not, in particular, a switch that can >> select old or new behavior) > I'm in favour of your proposed improvements, but I'm

Re: [HACKERS] [RFC: bug fix?] Connection attempt block forever when the synchronous standby is not running

FWIW a fix for this has been posted to all active branches: Author: Andres Freund Branch: master [fd6a3f3ad] 2015-02-26 12:50:07 +0100 Branch: REL9_4_STABLE [d72115112] 2015-02-26 12:50:07 +0100 Branch: REL9_3_STABLE [abce8dc7d] 2015-02-26 12:50:07 +0100 Branch: REL9_2_STABLE [d67076529] 2015-02

Re: [HACKERS] mogrify and indent features for jsonb

On 26 February 2015 at 15:09, Dmitry Dolgov <9erthali...@gmail.com> wrote: > Hi, Thom. > > > Would this support deleting "type" and the value 'dd' > > With this patch you can delete them one by one: > > select '{"a": 1, "b": 2, "c": {"type": "json", "stuff": "test"}, "d": > ["aa","bb","cc","dd"]}

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On 2/25/15 11:40 PM, Alvaro Herrera wrote: > Fujii Masao wrote: >> On Tue, Feb 24, 2015 at 1:29 AM, David Steele wrote: > >>> 1) Follow Oracle's "as session" option and only log each statement type >>> against an object the first time it happens in a session. This would >>> greatly reduce loggin

Re: [HACKERS] mogrify and indent features for jsonb

Hi, Thom. > Would this support deleting "type" and the value 'dd' With this patch you can delete them one by one: select '{"a": 1, "b": 2, "c": {"type": "json", "stuff": "test"}, "d": ["aa","bb","cc","dd"]}'::jsonb - '{c, type}'::text[] - '{d, -1}'::text[]; ?column?

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

On 2/25/15 10:42 PM, Fujii Masao wrote: > On Tue, Feb 24, 2015 at 1:29 AM, David Steele wrote: >> On 2/18/15 10:25 AM, David Steele wrote: >>> On 2/18/15 6:11 AM, Fujii Masao wrote: The pg_audit doesn't log BIND parameter values when prepared statement is used. Seems this is an ove

Re: [HACKERS] Primary not sending to synchronous standby

On 26 February 2015 at 13:08, Andres Freund wrote: > On 2015-02-23 17:09:24 +, Thom Brown wrote: > > On 23 February 2015 at 16:53, Andres Freund > wrote: > > > Comments? This is obviously just a POC, but I think something like this > > > does make a great deal of sense. > > > > > > Thom, doe

Re: [HACKERS] Primary not sending to synchronous standby

On 2015-02-23 17:09:24 +, Thom Brown wrote: > On 23 February 2015 at 16:53, Andres Freund wrote: > > Comments? This is obviously just a POC, but I think something like this > > does make a great deal of sense. > > > > Thom, does that help? > Yeah, this appears to eliminate the problem, at lea

Re: [HACKERS] New CF app deployment

On Thu, Feb 26, 2015 at 9:15 PM, Asif Naeem wrote: > This thread seems relevant, Please guide me to how can access older CF pages >> The MSVC portion of this fix got completely lost in the void: >> https://commitfest.postgresql.org/action/patch_view?id=1330 > > Above link result in the following e

Re: [HACKERS] How to create virtual indexes on postgres

But, it runs with Postgres 9.1 version...But I use 9.4..I think I cant use that. Or as an alternative Is there any provision in postgres to know use(Increase in Performance) of an index before creating that index. On Thu, Feb 26, 2015 at 5:37 PM, Michael Paquier wrote: > On Thu, Feb 26, 2015 at

Re: [HACKERS] New CF app deployment

Hi, This thread seems relevant, Please guide me to how can access older CF pages e.g. Thread http://www.postgresql.org/message-id/flat/51f19059.7050...@pgexperts.com#51f19059.7050...@pgexperts.com mentions following link i.e. The MSVC portion of this fix got completely lost in the void: > https:

Re: [HACKERS] How to create virtual indexes on postgres

On Thu, Feb 26, 2015 at 6:20 PM, Sreerama Manoj wrote: > So my question was can we know whether the planner will use the index > before actually creating a real Index..or can we create "virtual" or > "Hypothetical" Index those can only be known to the planner and not the user > or Is there any al

Re: [HACKERS] Bug in pg_dump

On Wed, Feb 25, 2015 at 7:46 AM, Gilles Darold wrote: > This is a far better patch and the test to export/import of the > postgis_topology extension works great for me. > > Thanks for the work. Attached is a patch that uses an even better approach by querying only once all the FK dependencies of

[HACKERS] BDR Multiple database

Hi all, I'm using PostgreSQL BDR 9.4.1 to test BDR capability right now $ psql --version psql (PostgreSQL) 9.4.1 We want to use BDR with multiple database but now all the document didn't show any example how to config BDR with multiple database. We've tried with many combination as below but sti

Re: [HACKERS] How about to have relnamespace and relrole?

Sorry, I fixed a silly typo in documentation in the previous version. - of theses types has a significance... + of these types has a significance... # My fingers frequently slip as above.. I incremented the version of this revised patch to get rid of confusion. === Hello, thank you

Re: [HACKERS] How about to have relnamespace and relrole?

Hello, thank you for reviewing. The attatched are the third version of this patch. 0001-Add-regrole_v3.patch 0002-Add-regnamespace_v3.patch - Rearranged into regrole patch and regnamespace patch as seen above, each of them consists of changes for code, docs, regtests. regnamespace patch depe

Re: [HACKERS] Refactoring GUC unit conversions

On Fri, Feb 13, 2015 at 10:26 PM, Heikki Linnakangas wrote: > In the "redesign checkpoint_segments" patch, Robert suggested keeping the > settings' base unit as "number of segments", but allow conversions from MB, > GB etc. I started looking into that and found that adding a new unit to > guc.c is

Re: [HACKERS] Review of GetUserId() Usage

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed I have reviewed the patch. Patch is excellent in shape and do

  1   2   >