[HACKERS] compiler warnings in lwlock

When building with LOCK_DEBUG but without casserts, I was getting unused variable warnings. I believe this is the correct way to silence them. Cheers, Jeff silence_lwlock_lock_debug.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make c

Re: [HACKERS] proposal: plpgsql - Assert statement

2015-03-26 0:08 GMT+01:00 Tom Lane : > Jim Nasby writes: > > On 3/25/15 1:21 AM, Pavel Stehule wrote: > >> 2015-03-25 0:17 GMT+01:00 Tom Lane >> >: > >>> (BTW, is considering > >>> NULL to be a failure the right thing? SQL CHECK conditions consider > >>> NULL to be al

Re: [HACKERS] pg_rewind in contrib

On Thu, Mar 26, 2015 at 12:23 PM, Venkata Balaji N wrote: > Test 1 : > > [...] > > If the master is crashed or killed abruptly, it may not be possible to do a > rewind. Is my understanding correct ? Yep. This is mentioned in the documentation: http://www.postgresql.org/docs/devel/static/app-pgrew

Re: [HACKERS] pg_rewind in contrib

> I have committed this, with some more kibitzing. hope I have not missed > any comments given so far. Many thanks for the review, and please continue > reviewing and testing it :-). I have been testing the pg_rewind and have an analysis to share along with few questions - I had a streaming rep

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

2015/03/26 10:51、Kouhei Kaigai のメール： > The attached patch adds GetForeignJoinPaths call on make_join_rel() only when > 'joinrel' is actually built and both of child relations are managed by same > FDW driver, prior to any other built-in join paths. > I adjusted the hook definition a little bit, b

Re: [HACKERS] Parallel Seq Scan

On Wed, Mar 25, 2015 at 9:53 PM, Thom Brown wrote: > > On 25 March 2015 at 15:49, Amit Kapila wrote: >> >> On Wed, Mar 25, 2015 at 5:16 PM, Thom Brown wrote: >> > Okay, with my pgbench_accounts partitioned into 300, I ran: >> > >> > SELECT DISTINCT bid FROM pgbench_accounts; >> > >> > The query

Re: [HACKERS] Re: [COMMITTERS] pgsql: btree_gin: properly call DirectFunctionCall1()

Bruce Momjian writes: > OK, I figured out that I was only supposed to change inet_in, not the > other calls to DirectFunctionCall3 (varbit_in and bit_in). Patch > attached. That looks better ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@p

Re: [HACKERS] Why SyncRepWakeQueue is not static?

>> Fix committed/pushed from master to 9.2. 9.1 declares it as a static >> function. > > Er, is that a good idea to back-patch that? Normally routine specs are > maintained stable on back-branches, and this is just a cosmetic > change. I'm not sure if it's a cosmetic change or not. I thought decl

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

> > Or bottom of make_join_rel(). IMO build_join_rel() is responsible for just > building (or searching from a list) a RelOptInfo for given relids. After that > make_join_rel() calls add_paths_to_joinrel() with appropriate arguments per > join > type to generate actual Paths implements the join.

Re: [HACKERS] Why SyncRepWakeQueue is not static?

On Thu, Mar 26, 2015 at 10:46 AM, Tatsuo Ishii wrote: >> SyncRepWakeQueue (src/backend/replication/syncrep.c) is not used >> anywhere except in the file. If there's no good reason for it, I think >> it should be declared as a static function. Included patch does so. > > Fix committed/pushed from

Re: [HACKERS] Moving on to close the current CF 2015-02

On Thu, Mar 26, 2015 at 10:41 AM, Bruce Momjian wrote: > On Thu, Mar 26, 2015 at 10:22:11AM +0900, Michael Paquier wrote: >> Hi all, >> >> Visibly there is no commit fest manager this time (was I?), and people >> may think that I still am the CFM for 2015-02, continuously after >> 2014-12 and that

Re: [HACKERS] Why SyncRepWakeQueue is not static?

> SyncRepWakeQueue (src/backend/replication/syncrep.c) is not used > anywhere except in the file. If there's no good reason for it, I think > it should be declared as a static function. Included patch does so. Fix committed/pushed from master to 9.2. 9.1 declares it as a static function. Best re

[HACKERS] GSoC 2015 proposal: Improve the performance of “ALTER TABLE .. SET LOGGED / UNLOGGED” statement

Hi all, Below I written my proposal idea to this GSoC. *** Improve the performance of “ALTER TABLE .. SET LOGGED / UNLOGGED” statement *** Last year during the GSoC2014 I implemented the feature to allow an unlogged table to be changed to logged [1], but the desing chosen was to rewrite the ent

Re: [HACKERS] Moving on to close the current CF 2015-02

On Thu, Mar 26, 2015 at 10:22:11AM +0900, Michael Paquier wrote: > Hi all, > > Visibly there is no commit fest manager this time (was I?), and people > may think that I still am the CFM for 2015-02, continuously after > 2014-12 and that I am severely slacking on my duties. Honestly I > thought tha

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On Wed, Mar 25, 2015 at 12:45 PM, Jim Nasby wrote: > > I see 3 settings that allow people to accidentally shoot themselves in the > foot; fsync, wal_sync_method and full_page_writes. > > How about just grouping those 3 together with a bulk disclaimer along the > lines of "The following 3 settings

[HACKERS] Moving on to close the current CF 2015-02

Hi all, Visibly there is no commit fest manager this time (was I?), and people may think that I still am the CFM for 2015-02, continuously after 2014-12 and that I am severely slacking on my duties. Honestly I thought that I was not and that it was clear enoug... Still, biting the bullet to make t

Re: [HACKERS] Error with index on unlogged table

On Thu, Mar 26, 2015 at 1:02 AM, Fabrízio de Royes Mello wrote: > On Wed, Mar 25, 2015 at 12:46 PM, Fabrízio de Royes Mello > wrote: >> >> >> On Wed, Mar 25, 2015 at 10:53 AM, Andres Freund >> wrote: >> > >> >> > Did you check whether a similar bug was made in other places of >> > 85b506bb? Coul

[HACKERS] Re: [COMMITTERS] pgsql: btree_gin: properly call DirectFunctionCall1()

On Tue, Mar 24, 2015 at 10:35:10PM -0400, Bruce Momjian wrote: > On Tue, Mar 24, 2015 at 10:02:03PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > btree_gin: properly call DirectFunctionCall1() > > > Previously we called DirectFunctionCall3() with dummy arguments. > > > > This patch is e

Re: [HACKERS] Error with index on unlogged table

On Wed, Mar 25, 2015 at 10:53 PM, Andres Freund wrote: > Hi, > > On 2015-03-25 11:38:30 +0900, Michael Paquier wrote: >> On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote: >> > The index is unlogged until reindexing... >> > >> > [...] >> > Which is think also raises the question, why are unlogged

Re: [HACKERS] [COMMITTERS] pgsql: Add macros wrapping all usage of gcc's __attribute__.

Andres Freund writes: > Add macros wrapping all usage of gcc's __attribute__. I noticed that this commit attached pg_attribute_noreturn not only to the extern declarations, but to some actual function definitions. I think this is a bad idea, because it's going to look like heck after pgindent get

Re: [HACKERS] proposal: plpgsql - Assert statement

Jim Nasby writes: > On 3/25/15 1:21 AM, Pavel Stehule wrote: >> 2015-03-25 0:17 GMT+01:00 Tom Lane > >: >>> (BTW, is considering >>> NULL to be a failure the right thing? SQL CHECK conditions consider >>> NULL to be allowed ...) >> This is a question - I am happy with

Re: [HACKERS] Abbreviated keys for Numeric

On Wed, Mar 25, 2015 at 6:26 PM, Andrew Gierth wrote: >> "Peter" == Peter Geoghegan writes: > > Peter> You still pointlessly check memtupcount here: > > Peter> + if (memtupcount < 1 || nss->input_count < 1 || > !nss->estimating) > Peter> + return false; > > It's in a register;

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On 3/22/15 4:50 PM, Greg Stark wrote: On Sun, Mar 22, 2015 at 3:34 PM, Euler Taveira wrote: On 21-03-2015 17:53, Josh Berkus wrote: Now, I have *long* been an advocate that we should ship a "stripped" PostgreSQL.conf which has only the most commonly used settings, and leave the rest of the set

Re: [HACKERS] Abbreviated keys for Numeric

> "Peter" == Peter Geoghegan writes: Peter> You still pointlessly check memtupcount here: Peter> + if (memtupcount < 1 || nss->input_count < 1 || !nss->estimating) Peter> + return false; It's in a register; the test is free. Peter> This cast to void is unnecessary: Peter

Re: [HACKERS] deparsing utility commands

Alvaro Herrera wrote: > Here's an updated version of this series. I just pushed patches 0001 and 0002, with very small tweaks; those had already been reviewed and it didn't seem like there was much controversy. To test the posted series it's probably easiest to git checkout b3196e65f5bfc9

Re: [HACKERS] GSoC 2015 proposal. Bitmap Index-only Count

Anastasia Lubennikova writes: > 2015-03-24 18:01 GMT+04:00 Tom Lane : >> I wonder whether it'd be possible to teach GIN to support index_getnext >> instead. Initially it would probably work only for cases where the >> index didn't have to return any columns ... but if we did it, maybe the >> door

Re: [HACKERS] Reduce pinning in btree indexes

Kevin Grittner wrote: > Kyotaro HORIGUCHI wrote: >> I attached the your latest patch to this mail as >> bt-nopin-v4.patch for now. Please check that there's no problem >> in it. > > I checked out master, applied the patch and checked it against my > latest code (merged with master), and it match

Re: [HACKERS] Remove fsync ON/OFF as a visible option?

On 3/21/15 12:25 PM, Jeff Janes wrote: On Sat, Mar 21, 2015 at 8:54 AM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote: Stephen Frost mailto:sfr...@snowman.net>> writes: > At the moment, one could look at our default postgresql.conf and the > "turns forced synchronization on or off" and

Re: [HACKERS] GSoC 2015 proposal. Bitmap Index-only Count

2015-03-24 18:01 GMT+04:00 Tom Lane : > Anastasia Lubennikova writes: > > There is a problem of slow counting in PostgreSQL [1]. The reason why > this > > is slow is related to the *MVCC* implementation in PostgreSQL. Index-only > > scans (implemented since PostgreSQL-9.2) providing some performa

Re: [HACKERS] deparsing utility commands

On Wed, Mar 25, 2015 at 11:59 AM, Alvaro Herrera wrote: > > > * Should we prohibit DDL from within event triggers? > Please don't prohibit DDL unless there is a really, really good reason to do so. I have several use cases in mind for event triggers, but they are only useful if I can perform DDL.

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

On 2015-03-25 14:50:44 -0400, Tom Lane wrote: > Jim Nasby writes: > > On 3/24/15 6:26 PM, Tom Lane wrote: > >> Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM > >> to the makefiles, but I did not hear one for adding it to pg_config; and > >> doing the former takes about t

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

Jim Nasby writes: > On 3/24/15 6:26 PM, Tom Lane wrote: >> Hm. We're all agreed that there's a use case for exposing PG_VERSION_NUM >> to the makefiles, but I did not hear one for adding it to pg_config; and >> doing the former takes about two lines whereas adding a pg_config option >> entails qu

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

On 3/24/15 6:26 PM, Tom Lane wrote: Andrew Gierth writes: "Tom" == Tom Lane writes: Tom> I concur with Michael that there's value in exposing the version Tom> number in the numeric form used by PG_VERSION_NUM. However, I Tom> also concur with Andrew that if the use-case for this is To

Re: [HACKERS] proposal: plpgsql - Assert statement

On 3/25/15 1:21 AM, Pavel Stehule wrote: 2015-03-25 0:17 GMT+01:00 Tom Lane mailto:t...@sss.pgh.pa.us>>: Pavel Stehule mailto:pavel.steh...@gmail.com>> writes: > updated version with Jim Nasby's doc and rebase against last changes in > plpgsql. I started looking at this patch.

Re: [HACKERS] What exactly is our CRC algorithm?

On 03/25/2015 07:20 PM, Andres Freund wrote: On 2015-03-25 19:18:51 +0200, Heikki Linnakangas wrote: Or better yet, a direct configure test to check if the intrinsic exists - that way we get to also use it on Intel compilers, which I believe also has the same intrinsics. Maybe I'm missing some

Re: [HACKERS] What exactly is our CRC algorithm?

On 2015-03-25 19:18:51 +0200, Heikki Linnakangas wrote: > I was just about to commit the attached, which is the same as the previous > patch with just cosmetic comment changes, but then I realized that this > probably doesn't compile with Visual Studio 2005 or older. The code does > "#ifdef _MSC_VE

Re: [HACKERS] What exactly is our CRC algorithm?

On 02/12/2015 09:26 PM, Heikki Linnakangas wrote: On 02/11/2015 04:20 PM, Abhijit Menon-Sen wrote: At 2015-02-11 13:20:29 +0200, hlinnakan...@vmware.com wrote: I don't follow. I didn't change configure at all, compared to your patch. OK, I extrapolated a little too much. Your patch didn't ac

Re: [HACKERS] INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0

On Wed, Mar 18, 2015 at 2:41 PM, Heikki Linnakangas wrote: > Here's what I had in mind: the inserter tags the tuple with the speculative > insertion token, by storing the token in the t_ctid field. If the inserter > needs to super-delete the tuple, it sets xmax like in a regular deletion, > but al

Re: [HACKERS] Parallel Seq Scan

On 25 March 2015 at 15:49, Amit Kapila wrote: > On Wed, Mar 25, 2015 at 5:16 PM, Thom Brown wrote: > > > > On 25 March 2015 at 10:27, Amit Kapila wrote: > >> > >> Fixed the reported issue on assess-parallel-safety thread and another > >> bug caught while testing joins and integrated with latest

Re: [HACKERS] Error with index on unlogged table

On Wed, Mar 25, 2015 at 12:46 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > On Wed, Mar 25, 2015 at 10:53 AM, Andres Freund wrote: > > > > > Did you check whether a similar bug was made in other places of > > 85b506bb? Could you additionally add a regression test to this end?

Re: [HACKERS] Parallel Seq Scan

On Wed, Mar 25, 2015 at 5:16 PM, Thom Brown wrote: > > On 25 March 2015 at 10:27, Amit Kapila wrote: >> >> Fixed the reported issue on assess-parallel-safety thread and another >> bug caught while testing joins and integrated with latest version of >> parallel-mode patch (parallel-mode-v9 patch).

Re: [HACKERS] Error with index on unlogged table

On Wed, Mar 25, 2015 at 10:53 AM, Andres Freund wrote: > > Hi, > > On 2015-03-25 11:38:30 +0900, Michael Paquier wrote: > > On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote: > > > The index is unlogged until reindexing... > > > > > > [...] > > > Which is think also raises the question, why are un

Re: [HACKERS] Ignoring entries generated by autoconf in code tree

Michael Paquier writes: > When running autoconf from the root tree, autom4te.cache/ is > automatically generated. > Wouldn't it make sense to add an entry in .gitignore for that? Personally, I don't want such a thing, as then I would tend to forget to remove that cache file. And you do want to r

[HACKERS] varlena.c hash_any() and hash_uint32() calls require DatumGetUInt32()

Attached patch adds DatumGetUInt32() around the hash_any() and hash_uint32() calls within varlena.c. These should have been in the original abbreviated keys commit. Mea culpa. -- Peter Geoghegan diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c index 3edd283..02e9949

Re: [HACKERS] Error with index on unlogged table

Hi, On 2015-03-25 11:38:30 +0900, Michael Paquier wrote: > On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote: > > The index is unlogged until reindexing... > > > > [...] > > Which is think also raises the question, why are unlogged indexes made > > persistent by a reindex? > > That's a bug of HEA

Re: [HACKERS] Error with index on unlogged table

On Wednesday, March 25, 2015, Thom Brown wrote: > On 25 March 2015 at 12:22, Amit Langote > wrote: > >> On Wednesday, March 25, 2015, Michael Paquier > > wrote: >> > >> > On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote: >> > > The index is unlogged until reindexing... >> > > >> > > [...] >> >

Re: [HACKERS] Parallel Seq Scan

On 25 March 2015 at 11:46, Thom Brown wrote: > > > Still not sure why 8 workers are needed for each partial scan. I would > expect 8 workers to be used for 8 separate scans. Perhaps this is just my > misunderstanding of how this feature works. > Another issue: SELECT * FROM pgb *crash* Logs:

Re: [HACKERS] Abbreviated keys for Numeric

On Tue, Mar 24, 2015 at 12:03 AM, Andrew Gierth wrote: > So here's the latest (and, hopefully, last) version: > > - adds diagnostic output from numeric_abbrev_abort using the trace_sort >GUC > > - fixed Datum cs. uint32 issues in hash_uint32 > > - added a short comment about excess-k repres

Re: [HACKERS] Auditing extension for PostgreSQL (Take 2)

On 3/25/15 7:46 AM, Sawada Masahiko wrote: > On Wed, Mar 25, 2015 at 12:23 PM, David Steele wrote: >>> On Wed, Mar 25, 2015 at 12:38 AM, David Steele wrote: > 2. OBJECT auditing does not work before adding acl info to > pg_class.rel_acl. > In following situation, pg_audit can not aud

Re: [HACKERS] printing table in asciidoc with psql

On Wed, Mar 25, 2015 at 09:37:08PM +0900, Michael Paquier wrote: > On Wed, Mar 25, 2015 at 4:59 PM, Bruce Momjian wrote: > > On Wed, Mar 25, 2015 at 02:18:58PM +0900, Michael Paquier wrote: > >> > [options="header",cols=" >> > | > >> > |5 2.2+^.^ |4 2.2+^.^ > >> > |2 2.2+^.^ |3 2.2+^.^ > >> >

Re: [HACKERS] Error with index on unlogged table

On 25 March 2015 at 12:22, Amit Langote wrote: > On Wednesday, March 25, 2015, Michael Paquier > wrote: > > > > On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote: > > > The index is unlogged until reindexing... > > > > > > [...] > > > Which is think also raises the question, why are unlogged ind

Re: [HACKERS] printing table in asciidoc with psql

On Wed, Mar 25, 2015 at 4:59 PM, Bruce Momjian wrote: > On Wed, Mar 25, 2015 at 02:18:58PM +0900, Michael Paquier wrote: >> > [options="header",cols="> > | >> > |5 2.2+^.^ |4 2.2+^.^ >> > |2 2.2+^.^ |3 2.2+^.^ >> > | >> >> Hm. This is still incorrect. You should remove options="header" her

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

> 2015/03/25 19:47、Kouhei Kaigai のメール： > > The reason why FDW handler was called multiple times on your example is, > > your modified make_join_rel() does not check whether build_join_rel() > > actually build a new RelOptInfo, or just a cache reference, doesn't it? > > > > Yep. After that change

Re: [HACKERS] Error with index on unlogged table

On Wednesday, March 25, 2015, Michael Paquier wrote: > > On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote: > > The index is unlogged until reindexing... > > > > [...] > > Which is think also raises the question, why are unlogged indexes made > > persistent by a reindex? > > That's a bug of HEAD,

Re: [HACKERS] Auditing extension for PostgreSQL (Take 2)

On Wed, Mar 25, 2015 at 12:23 PM, David Steele wrote: >> On Wed, Mar 25, 2015 at 12:38 AM, David Steele wrote: 2. OBJECT auditing does not work before adding acl info to pg_class.rel_acl. In following situation, pg_audit can not audit OBJECT log. $ cat postgresql.conf | grep

Re: [HACKERS] Parallel Seq Scan

On 25 March 2015 at 10:27, Amit Kapila wrote: > On Fri, Mar 20, 2015 at 5:36 PM, Amit Kapila > wrote: > > > > > > So the patches have to be applied in below sequence: > > HEAD Commit-id : 8d1f2390 > > parallel-mode-v8.1.patch [2] > > assess-parallel-safety-v4.patch [1] > > parallel-heap-scan.pat

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

2015/03/25 19:47、Kouhei Kaigai のメール： > The reason why FDW handler was called multiple times on your example is, > your modified make_join_rel() does not check whether build_join_rel() > actually build a new RelOptInfo, or just a cache reference, doesn't it? > Yep. After that change calling cou

[HACKERS] Ignoring entries generated by autoconf in code tree

Hi all, When running autoconf from the root tree, autom4te.cache/ is automatically generated. Wouldn't it make sense to add an entry in .gitignore for that? Regards, -- Michael diff --git a/.gitignore b/.gitignore index 8d3af50..b1f04bb 100644 --- a/.gitignore +++ b/.gitignore @@ -28,6 +28,7 @@ l

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

2015/03/25 18:53、Ashutosh Bapat のメール： > > > On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA > wrote: > > Or bottom of make_join_rel(). IMO build_join_rel() is responsible for just > building (or searching from a list) a RelOptInfo for given relids. After > that make_join_rel() calls add

Re: [HACKERS] Parallel Seq Scan

On Wed, Mar 25, 2015 at 4:08 PM, Rajeev rastogi wrote: > > On 25 March 2015 16:00, Amit Kapila Wrote: > > > Which version of patch you are looking at? > > > I am seeing below code in ExecInitFunnel() in Version-11 to which > > > you have replied. > > > > > + /* Funnel node doesn't have innerPlan

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

> 2015/03/25 19:09、Kouhei Kaigai のメール： > > >> On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA > wrote: > >>Or bottom of make_join_rel(). IMO build_join_rel() is responsible for > >> just building (or searching from a list) a RelOptInfo for given relids. > >> After > >> that make_join_rel(

Re: [HACKERS] Parallel Seq Scan

On 25 March 2015 16:00, Amit Kapila Wrote: > Which version of patch you are looking at? > I am seeing below code in ExecInitFunnel() in Version-11 to which > you have replied. > + /* Funnel node doesn't have innerPlan node. */ > + Assert(innerPlan(node) == NULL I was seeing the version-10. I

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

> 2015/03/25 12:59、Kouhei Kaigai のメール： > > >>> At this moment, I'm not 100% certain about its logic. Especially, I didn't > >>> test SEMI- and ANTI- join cases yet. > >>> However, time is money - I want people to check overall design first, > >>> rather > >>> than detailed debugging. Please tell

Re: [HACKERS] assessing parallel-safety

On Fri, Mar 20, 2015 at 11:37 PM, Robert Haas wrote: > > > That might be a different crash than the first one you showed. But it > looks like the problem here is that the parallel sequential scan patch > is calling CreateParallelContext even though this is just an EXPLAIN > and we're not actually

Re: [HACKERS] assessing parallel-safety

On Sun, Mar 22, 2015 at 12:00 AM, Thom Brown wrote: > > On 21 March 2015 at 14:28, Amit Kapila wrote: >> >> On Fri, Mar 20, 2015 at 7:54 PM, Thom Brown wrote: >> > createdb pgbench >> > pgbench -i -s 200 pgbench >> > >> > CREATE TABLE pgbench_accounts_1 (CHECK (bid = 1)) INHERITS (pgbench_accoun

Re: [HACKERS] Parallel Seq Scan

On Wed, Mar 25, 2015 at 3:47 PM, Rajeev rastogi wrote: > > On 20 March 2015 17:37, Amit Kapila Wrote: > > > So the patches have to be applied in below sequence: > > HEAD Commit-id : 8d1f2390 > > parallel-mode-v8.1.patch [2] > > assess-parallel-safety-v4.patch [1] > > parallel-heap-scan.patch [3]

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

2015/03/25 19:09、Kouhei Kaigai のメール： >> On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA >> wrote: >> Or bottom of make_join_rel(). IMO build_join_rel() is responsible for >> just building (or searching from a list) a RelOptInfo for given relids. >> After >> that make_join_rel() calls a

Re: [HACKERS] Parallel Seq Scan

On 20 March 2015 17:37, Amit Kapila Wrote: > So the patches have to be applied in below sequence: > HEAD Commit-id : 8d1f2390 > parallel-mode-v8.1.patch [2] > assess-parallel-safety-v4.patch [1] > parallel-heap-scan.patch [3] > parallel_seqscan_v11.patch (Attached with this mail) While I was goin

Re: [HACKERS] possible dsm bug in dsm_attach()

On Tue, May 6, 2014 at 11:15 PM, Robert Haas wrote: > > On Tue, May 6, 2014 at 1:14 PM, Andres Freund wrote: > > On 2014-05-06 08:48:57 -0400, Robert Haas wrote: > >> On Tue, May 6, 2014 at 8:43 AM, Andres Freund wrote: > >> > The break because of refcnt == 1 doesn't generally seem to be a good

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

> On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA > wrote: > Or bottom of make_join_rel(). IMO build_join_rel() is responsible for > just building (or searching from a list) a RelOptInfo for given relids. After > that make_join_rel() calls add_paths_to_joinrel() with appropriate arguments

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

On Wed, Mar 25, 2015 at 3:14 PM, Shigeru HANADA wrote: > > Or bottom of make_join_rel(). IMO build_join_rel() is responsible for > just building (or searching from a list) a RelOptInfo for given relids. > After that make_join_rel() calls add_paths_to_joinrel() with appropriate > arguments per jo

Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)

2015/03/25 12:59、Kouhei Kaigai のメール： >>> At this moment, I'm not 100% certain about its logic. Especially, I didn't >>> test SEMI- and ANTI- join cases yet. >>> However, time is money - I want people to check overall design first, rather >>> than detailed debugging. Please tell me if I misunders

Re: [HACKERS] recovery_target_time ignored ?

On Wed, Mar 25, 2015 at 1:28 AM, David Steele wrote: > On 3/24/15 6:12 AM, Venkata Balaji N wrote: > > > > On Tue, Mar 24, 2015 at 9:54 AM, David Steele > > wrote: > > > > On 3/23/15 12:42 AM, Venkata Balaji N wrote: > > > Hi, > > > > > > Assuming that

Re: [HACKERS] printing table in asciidoc with psql

On Wed, Mar 25, 2015 at 02:18:58PM +0900, Michael Paquier wrote: > > [options="header",cols=" > | > > |5 2.2+^.^ |4 2.2+^.^ > > |2 2.2+^.^ |3 2.2+^.^ > > | > > Hm. This is still incorrect. You should remove options="header" here > or the first tuple is treated as a header in the case > non

Re: [HACKERS] Custom/Foreign-Join-APIs

Hello, I had a look on this. At Wed, 25 Mar 2015 03:59:28 +, Kouhei Kaigai wrote in <9a28c8860f777e439aa12e8aea7694f8010c6...@bpxm15gp.gisp.nec.co.jp> > > > At this moment, I'm not 100% certain about its logic. Especially, I didn't > > > test SEMI- and ANTI- join cases yet. > > > However, ti