Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On Wed, Dec 16, 2015 at 1:29 PM, Tom Lane wrote: > I did some more experimentation and concluded that actually, this problem > has nothing whatsoever to do with pager invocations. What seems to really > be happening is that libreadline activates its SIGWINCH handler only

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Tom Lane wrote: > I did some more experimentation and concluded that actually, this problem > has nothing whatsoever to do with pager invocations. What seems to really > be happening is that libreadline activates its SIGWINCH handler only while > it's being called to collect input, which is fine

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Merlin Moncure writes: > On Wed, Dec 16, 2015 at 1:29 PM, Tom Lane wrote: >> So I now think that print.c shouldn't be involved at all, and the right >> thing to do is just have gets_interactive() invoke the resize function >> immediately before calling

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

I wrote: > Merlin Moncure writes: >> See https://bugs.python.org/issue23735 for background. Apparently >> this is expected behavior (and we are far from the only ones >> complaining about it): >> "And so we reach where we are. If a SIGWINCH arrives while readline is >> not

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Andres Freund writes: > Hm. rl_reset_screen_size() works well for me. rl_resize_terminal() not > so much. Apparently the reason for that is that rl_reset_screen_size() > doesn't set ignore_env to to true when calling > _rl_get_screen_size(). I've verified that just toggling

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Wed, Dec 9, 2015 at 5:15 PM, Peter Geoghegan wrote: > On Wed, Dec 9, 2015 at 11:31 AM, Robert Haas wrote: >> I find the references to a "void" representation in this patch to be >> completely opaque. I see that there are some such references in >>

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Sat, Dec 12, 2015 at 8:03 AM, Amit Kapila wrote: >> I think it might be >> advantageous to have at least two groups because otherwise things >> might slow down when some transactions are rolling over to a new page >> while others are still in flight for the previous

Re: [HACKERS] checkpointer continuous flushing

Hello Tomas, I'm planning to do some thorough benchmarking of the patches proposed in this thread, on various types of hardware (10k SAS drives and SSDs). But is that actually needed? I see Andres did some testing, as he posted summary of the results on 11/12, but I don't see any actual

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

I did some more experimentation and concluded that actually, this problem has nothing whatsoever to do with pager invocations. What seems to really be happening is that libreadline activates its SIGWINCH handler only while it's being called to collect input, which is fine in itself, but *it does

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Wed, Dec 16, 2015 at 9:36 AM, Robert Haas wrote: >> That isn't what is intended. "void" is the state that macros like >> index_getattr() leave NULL leading attributes (that go in the >> SortTuple.datum1 field) in. > > What kind of state is that? Can't we define this in

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Alvaro Herrera writes: >> I did some more experimentation and concluded that actually, this problem >> has nothing whatsoever to do with pager invocations. What seems to really >> be happening is that libreadline activates its SIGWINCH handler only while >> it's being

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Tue, Nov 17, 2015 at 6:50 PM, Peter Geoghegan wrote: > On Tue, Nov 17, 2015 at 12:53 AM, Simon Riggs wrote: >> Short and sweet! Looks good. > > Thanks. > >> I would be inclined to add more comments to explain it, these things have a >> habit of being

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Alvaro Herrera wrote: > I wonder if we're doing the proper things. According to their manual, > http://git.savannah.gnu.org/gitweb/?p=readline.git;a=blob_plain;f=doc/readline.html;h=9b7dd842764c81ad496c38a2794361cad964ee90;hb=7628b745a813aac53586b640da056a975f1c443e#SEC44 Note: the above link

Re: [HACKERS] On-demand running query plans using auto_explain and signals

Hi, On 12/01/2015 10:34 AM, Shulgin, Oleksandr wrote: I have the plans to make something from this on top of pg_stat_statements and auto_explain, as I've mentioned last time. The next iteration will be based on the two latest patches above, so it still makes sense to review them. As for

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On Wed, Dec 16, 2015 at 12:06 PM, Andres Freund wrote: > On 2015-12-16 13:02:25 -0500, Tom Lane wrote: >> I think the most reasonable way to handle this is to put the >> call into a new function exported from input.c, where it can be >> made conditional on useReadline. > >

Re: [HACKERS] Tab-comletion for RLS

On Fri, Dec 11, 2015 at 11:56 AM, Masahiko Sawada wrote: > On Thu, Dec 10, 2015 at 11:07 PM, Robert Haas wrote: >> On Tue, Dec 8, 2015 at 8:32 AM, Masahiko Sawada >> wrote: >>> I found some lacks of tab-completion for RLS in

Re: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

On 2015-12-11 10:08:32 -0800, Jeff Janes wrote: > This is still in regular mode, correct? Yes. > I don't think this has ever worked. Vacuum needs to start a > transaction in order to record its update of datfrozenxid and > relfrozenxid to the catalogs (or at least, starts one for something). >

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On 2015-12-16 13:02:25 -0500, Tom Lane wrote: > > If we really want to we could basically directly use > > _rl_get_screen_size() - which seems to have been present from before > > 4.0. It's not declared static... > > Nah, I don't think we should rely on calling undocumented internal > readline

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On 2015-12-16 12:02:26 -0500, Tom Lane wrote: > [ squint... ] What readline version are you using, and do you have > LINES/COLUMNS set in your terminal environment? libreadline-dev: Installed: 6.3-8+b4 Both are set - I think bash does that. > It may be that the echo stuff is not good, but

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Andres Freund writes: > ... based on that I'm inclined to just go with resize - redisplaying the > query after the pager might be desirable, but I think it's an actual > behavioural change. Hmm ... given that we've not printed "Time:" yet (in \timing mode), I think you're

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On 2015-12-16 12:23:28 -0500, Tom Lane wrote: > It may be that we can't fix this in readline versions that precede the > introduction of the resize function. Let me go experiment on my pet > dinosaurs. I'm not particularly bothered by not supporting old readline versions here. If we really want

Re: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

On Fri, Dec 11, 2015 at 1:08 PM, Jeff Janes wrote: > Since changes to datfrozenxid are WAL logged at the time they occur, > but the supposedly-synchronous change to ShmemVariableCache is not WAL > logged until the next checkpoint, a well timed crash can leave you in > the

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Andres Freund writes: > On 2015-12-16 12:23:28 -0500, Tom Lane wrote: >> It may be that we can't fix this in readline versions that precede the >> introduction of the resize function. Let me go experiment on my pet >> dinosaurs. > I'm not particularly bothered by not

Re: [HACKERS] use_remote_estimate usage for join pushdown in postgres_fdw

On Fri, Dec 11, 2015 at 4:44 AM, Ashutosh Bapat wrote: > Hi All, > postgres_fdw documentation says following about use_remote_estimate > (http://www.postgresql.org/docs/devel/static/postgres-fdw.html) > -- > use_remote_estimate > This option, which can be

Re: [HACKERS] checkpointer continuous flushing

Hi, I'm planning to do some thorough benchmarking of the patches proposed in this thread, on various types of hardware (10k SAS drives and SSDs). But is that actually needed? I see Andres did some testing, as he posted summary of the results on 11/12, but I don't see any actual results or

Re: [HACKERS] use_remote_estimate usage for join pushdown in postgres_fdw

Robert Haas writes: > I like option #2. I don't really have a strong reason for that, but > it feels intuitive to me that we err on the side of using remote > estimates when in doubt. If we believe that, why isn't the default value of use_remote_estimate true? (Maybe it

Re: [HACKERS] use_remote_estimate usage for join pushdown in postgres_fdw

On Wed, Dec 16, 2015 at 1:11 PM, Tom Lane wrote: > Robert Haas writes: >> I like option #2. I don't really have a strong reason for that, but >> it feels intuitive to me that we err on the side of using remote >> estimates when in doubt. > > If we

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

On 17 December 2015 at 05:02, Tomas Vondra wrote: > 0) I know the patch does not tweak costing - any plans in this > direction? Would it be possible to simply use the costing used by >semijoin? > > Many thanks for looking at this. The patch does tweak the

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Wed, Dec 16, 2015 at 12:28 PM, Robert Haas wrote: >> I seem to be able to produce these sorting patches at a much greater >> rate than they can be committed, in part because Robert is the only >> one that ever reviews them, and he is only one person. > > I object to that

Re: [HACKERS] Reducing ClogControlLock contention

On 22 August 2015 at 15:14, Andres Freund wrote: > TransactionIdSetPageStatus() calls TransactionIdSetStatusBit(), which > writes an 8 byte variable (the lsn). That's not safe. > This point was the main sticking point here. It turns out that we don't need to store the LSN

Re: [HACKERS] Remove array_nulls?

On Tue, Dec 15, 2015 at 1:26 AM, Michael Paquier wrote: > On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby wrote: >> On 12/11/15 2:57 PM, Tom Lane wrote: >>> Jim Nasby writes: >>> Perhaps, but I'd like to have a less

[HACKERS] A Typo in regress/sql/privileges.sql

Hi, This is my first post to -hackers. I found typos in privileges.sql and privileges.out Please find attached a patch. Best regards, Tatsuro Yamada *** a/src/test/regress/expected/privileges.out --- b/src/test/regress/expected/privileges.out *** *** 390,396 INSERT INTO

Re: [HACKERS] parallel joins, and better parallel explain

On Wed, Dec 16, 2015 at 9:55 PM, Dilip Kumar wrote: > On Wed, Dec 16, 2015 at 6:20 PM Amit Kapila > wrote: > > >On Tue, Dec 15, 2015 at 7:31 PM, Robert Haas > wrote: > >> > >> On Mon, Dec 14, 2015 at 8:38 AM, Amit Kapila

Re: [HACKERS] Making tab-complete.c easier to maintain

Hello. Ok, I withdraw the minilang solution and I'll go on Thomas's way, which is still good to have. At Mon, 14 Dec 2015 14:13:02 +0900, Michael Paquier wrote in > On Mon, Dec 14, 2015 at 8:10 AM,

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Dec 10, 2015 at 3:31 AM, Robert Haas wrote: > On Mon, Nov 30, 2015 at 12:58 PM, Bruce Momjian wrote: >> On Mon, Nov 30, 2015 at 10:48:04PM +0530, Masahiko Sawada wrote: >>> On Sun, Nov 29, 2015 at 2:21 AM, Jeff Janes wrote:

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Sun, Oct 4, 2015 at 2:07 AM, Peter Geoghegan wrote: > On Sat, Oct 3, 2015 at 6:38 AM, Andres Freund wrote: >> I'm not arguing against any of this - but I don't think this needs to be >> on the 9.5 open items list. I plan to remove from there. > > Obviously

Re: [HACKERS] extend pgbench expressions with functions

On Wed, Dec 16, 2015 at 3:07 PM, Fabien COELHO wrote: > >> On Wed, Dec 16, 2015 at 6:10 AM, Robert Haas >> wrote: >>> >>> It looks fine to me except that I think we should spell out "param" as >>> "parameter" throughout, instead of abbreviating. >> >>

Re: [HACKERS] extend pgbench expressions with functions

Michael Paquier wrote: > On Wed, Dec 16, 2015 at 6:10 AM, Robert Haas wrote: > > On Mon, Dec 14, 2015 at 7:25 AM, Michael Paquier > > wrote: > >> I have looked for now at the first patch and finished with the > >> attached while looking at it.

Re: [HACKERS] extend pgbench expressions with functions

On Thu, Dec 17, 2015 at 1:54 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Wed, Dec 16, 2015 at 6:10 AM, Robert Haas wrote: >> > On Mon, Dec 14, 2015 at 7:25 AM, Michael Paquier >> > wrote: >> >> I have

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

On Thu, Sep 3, 2015 at 6:10 AM, Vladimir Borodin wrote: > Patch with implementation attached. > Sorry for delay, I will link it to the current commitfest. This patch looks correct, and is doing what it claims it does. It is also not really worth refactoring the bit of code in PrefetchBuffer that

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

On 17 December 2015 at 00:17, Tomas Vondra wrote: > 1) nodeHashjoin.c (and other join nodes) >> >> I've noticed we have this in the ExecHashJoin() method: >> >> /* >>* When the inner side is unique or we're performing a >>* semijoin,

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Dec 17, 2015 at 3:44 PM, Simon Riggs wrote: > For me, rewriting the visibility map is a new data loss bug waiting to > happen. I am worried that the group is not taking seriously the potential > for catastrophe here. FWIW, I'm following this line and merging the vm

Re: [HACKERS] extend pgbench expressions with functions

On Thu, Dec 17, 2015 at 1:42 PM, Michael Paquier wrote: > In conclusion, for this CF the patch doing the documentation fixes is > "Ready for committer", the second patch introducing the function > infrastructure should focus more on its core structure and should be >

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Dec 17, 2015 at 3:06 PM, Kyotaro HORIGUCHI wrote: > At Mon, 14 Dec 2015 14:13:02 +0900, Michael Paquier > wrote in > >> On Mon, Dec 14, 2015 at 8:10 AM,

Re: [HACKERS] Freeze avoidance of very large table.

On 9 December 2015 at 18:31, Robert Haas wrote: > On Mon, Nov 30, 2015 at 12:58 PM, Bruce Momjian wrote: > > On Mon, Nov 30, 2015 at 10:48:04PM +0530, Masahiko Sawada wrote: > >> On Sun, Nov 29, 2015 at 2:21 AM, Jeff Janes > wrote:

Re: [HACKERS] Freeze avoidance of very large table.

On 2015-12-17 15:56:35 +0900, Michael Paquier wrote: > On Thu, Dec 17, 2015 at 3:44 PM, Simon Riggs wrote: > > For me, rewriting the visibility map is a new data loss bug waiting to > > happen. I am worried that the group is not taking seriously the potential > > for

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Dec 17, 2015 at 4:10 PM, Andres Freund wrote: > On 2015-12-17 15:56:35 +0900, Michael Paquier wrote: >> On Thu, Dec 17, 2015 at 3:44 PM, Simon Riggs wrote: >> > For me, rewriting the visibility map is a new data loss bug waiting to >> > happen.

Re: [HACKERS] Multi-tenancy with RLS

Rebased patch is attached as it is having an OID conflict with the latest set of changes in the master branch. Regards, Hari Babu Fujitsu Australia 4_database_catalog_tenancy_v3.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Disabling an index temporarily

On 12/16/15 12:15 AM, Jeff Janes wrote: But also, while loading 1.5 million records into a table with 250 million records is horribly, rebuilding all the indexes on a 251.5 million record table from scratch is even more horrible. I don't know if suspending maintenance (either globally or just

Re: [HACKERS] Proposal: custom compression methods

On Wed, Dec 16, 2015 at 10:17 PM, Andres Freund wrote: > Again. Unless I miss something that was solved in > www.postgresql.org/message-id/flat/20130615102028.gk19...@alap2.anarazel.de > > Personally I think we should add lz4 and maybe on strongly compressing > algorithm and

Re: [HACKERS] Proposal: custom compression methods

On 12/16/15 7:03 AM, Tomas Vondra wrote: While versioning or increasing the 1GB limit are interesting, they have nothing to do with this particular patch. (BTW I don't see how the versioning would work at varlena level - that's something that needs to be handled at data type level). Right,

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

Hi, On 12/16/2015 11:40 PM, David Rowley wrote: On 17 December 2015 at 05:02, Tomas Vondra > wrote: 0) I know the patch does not tweak costing - any plans in this direction? Would it be possible to simply use the

Re: [HACKERS] [PATCH] Logical decoding support for sequence advances

On 15 December 2015 at 20:17, Andres Freund wrote: > > > I think this is quite the wrong approach. You're calling the logical > decoding callback directly from decode.c, circumventing > reorderbuffer.c. While you don't need the actual reordering, you *do* > need the snapshot

Re: [HACKERS] Remove array_nulls?

On 12/16/15 6:01 PM, Robert Haas wrote: On Tue, Dec 15, 2015 at 1:26 AM, Michael Paquier wrote: On Tue, Dec 15, 2015 at 2:57 AM, Jim Nasby wrote: On 12/11/15 2:57 PM, Tom Lane wrote: Jim Nasby writes: Perhaps,

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Wed, Dec 16, 2015 at 11:44 PM, Peter Geoghegan wrote: >> In any case, at this point 9.5 is really aimed to be stabilized, so >> targeting only master is a far saner approach IMO for this patch. >> Pushing that in 9.5 a couple of months back may have given enough >> reason to

[HACKERS] pg_tables bug?

I'm playing around with tablespace (postgresq 9.4) and I found out what I believe is a bug in pg_tables. Basically if you create a database in a table space X and then you create a table on the database the table is created correctly on the tablespace X ( I did a check on the filesystem) however

Re: [HACKERS] Freeze avoidance of very large table.

On 2015-12-17 16:22:24 +0900, Michael Paquier wrote: > On Thu, Dec 17, 2015 at 4:10 PM, Andres Freund wrote: > > On 2015-12-17 15:56:35 +0900, Michael Paquier wrote: > >> On Thu, Dec 17, 2015 at 3:44 PM, Simon Riggs wrote: > >> > For me, rewriting the

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Wed, Dec 16, 2015 at 11:20 PM, Michael Paquier wrote: > (A couple of months later) > This is not an actual fix, but an optimization, no? > UNIQUE_CHECK_SPECULATIVE is just used to optimize a couple of code > paths in the case of a insert conflicting during btree

Re: [HACKERS] Parallel Aggregate

On 16 December 2015 at 18:11, Haribabu Kommi wrote: > On Tue, Dec 15, 2015 at 8:04 AM, Paul Ramsey > wrote: > > But the run dies. > > > > NOTICE: SRID value -32897 converted to the officially unknown SRID > value 0 > > ERROR: Unknown

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On 12/14/2015 01:57 PM, Merlin Moncure wrote: This may be moot; some testing demonstrated that libedit was not impacted so it really comes down to having the right readline api call available. Looking at the code ISTM that libedit resets the terminal on every prompt. Did you manage to figure

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Wed, Dec 16, 2015 at 7:14 PM, Magnus Hagander wrote: > On Wed, Dec 16, 2015 at 8:34 AM, Michael Paquier > wrote: >> Interesting. I got just today a bug report that is actually a symptom >> that people should be careful about: it is possible that

Re: [HACKERS] Cube extension kNN support

Hi, On 12/16/2015 01:26 PM, Stas Kelvich wrote: Hi, thanks for the review. 1) (nitpicking) There seem to be some minor whitespace issues, i.e. trailing spaces, empty lines being added/removed, etc. Fixed, I think 2) one of the regression tests started to fail SELECT

Re: [HACKERS] Proposal: custom compression methods

Hi, On 12/14/2015 12:51 PM, Simon Riggs wrote: On 13 December 2015 at 17:28, Alexander Korotkov > wrote: it would be nice to make compression methods pluggable. Agreed. My thinking is that this should be combined with work to

Re: [HACKERS] Passing initially_valid values instead of !skip_validation to StoreRelCheck() in AddRelationNewConstraints()

On Wed, Dec 16, 2015 at 3:34 AM, amul sul wrote: > Updated patch to add this table creation case in regression tests. > PFA patch version V3. I committed the previous version just now after fixing various things. In particular, you added a function called from one place

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

On Wed, Dec 16, 2015 at 6:04 PM, Robert Haas wrote: > > On Wed, Dec 16, 2015 at 1:34 AM, Amit Kapila wrote: > > Yes, thats one thing I wanted to know, yet another point which is not > > clear to me about this Async infrastructure is why the current

Re: [HACKERS] Proposal: custom compression methods

On 2015-12-16 14:14:36 +0100, Tomas Vondra wrote: > I think the main obstacle to make this possible is the lack of free space in > varlena header / need to add the ID of the compression method into the > value. > > FWIW I'd like to allow this (mixing compression types), but I don't think > it's

Re: [HACKERS] Re: Potential pointer dereference in plperl.c (caused by transforms patch)

Noah Misch wrote: > fcinfo->flinfo->fn_oid==InvalidOid implies an inline block, and those have no > arguments. If it placates Coverity, I lean toward an assert-only change: > > --- a/src/pl/plperl/plperl.c > +++ b/src/pl/plperl/plperl.c This was committed as d4b686af0b. -- Álvaro Herrera

Re: [HACKERS] Cube extension kNN support

> I don't think that's what the comment says, actually. It rather refers to > code like this: > >result = Min(LL_COORD(c, n - 1), UR_COORD(c, n - 1)); > > i.e. if you specifically ask for a particular corner (ll, in this case), > you'll get the proper value. Hmm, I was confused by phrase

Re: [HACKERS] pgbench stats per script & other stuff

Here is a two part v12, which: part a (refactoring of scripts and their stats): - fix option checks (-i alone) - s/repleacable/replaceable/ in doc - keep small description in doc and help for -S & -N - fix 2 comments for pg style - show builtin list if not found part b (weight) - check

Re: [HACKERS] Cube extension kNN support

Hi, thanks for the review. > 1) (nitpicking) There seem to be some minor whitespace issues, i.e. > trailing spaces, empty lines being added/removed, etc. Fixed, I think > 2) one of the regression tests started to fail > > SELECT '-1e-700'::cube AS cube; > > This used to return (0) but

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

On Wed, Dec 16, 2015 at 1:34 AM, Amit Kapila wrote: > Yes, thats one thing I wanted to know, yet another point which is not > clear to me about this Async infrastructure is why the current > infrastructure > of Parallelism can't be used to achieve the Async benefits of

Re: [HACKERS] Proposal: custom compression methods

On 12/14/2015 07:28 PM, Jim Nasby wrote: On 12/14/15 12:50 AM, Craig Ringer wrote: The issue with per-Datum is that TOAST claims two bits of a varlena header, which already limits us to 1 GiB varlena values, something people are starting to find to be a problem. There's no wiggle room to

Re: [HACKERS] parallel joins, and better parallel explain

On Tue, Dec 15, 2015 at 7:31 PM, Robert Haas wrote: > > On Mon, Dec 14, 2015 at 8:38 AM, Amit Kapila wrote: > > set enable_hashjoin=off; > > set enable_mergejoin=off; > > [ ... ] > > > > Now here the point to observe is that non-parallel case uses

Re: [HACKERS] Proposal: custom compression methods

Hi, On 12/13/2015 06:28 PM, Alexander Korotkov wrote: > Compression method of column would be stored in pg_attribute table. Dependencies between columns and compression methods would be tracked in pg_depend preventing dropping compression method which is currently in use. Compression method of

Re: [HACKERS] parallel joins, and better parallel explain

On Wed, Dec 16, 2015 at 6:20 PM Amit Kapila wrote: >On Tue, Dec 15, 2015 at 7:31 PM, Robert Haas wrote: >> >> On Mon, Dec 14, 2015 at 8:38 AM, Amit Kapila wrote: > In any case, >I have done some more investigation of the

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

Hi, On 12/16/2015 01:27 AM, David Rowley wrote: I've attached a rebased patch against current master as there were some conflicts from the recent changes to LATERAL join. Thanks. I've looked at the rebased patch and have a few minor comments. 0) I know the patch does not tweak costing - any

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Andreas Karlsson writes: > Did you manage to figure out why one was better than the other? The > differences between the functions seem rather subtle. I'm a bit suspicious of Merlin's recommendation as well. Looking at the readline 6.3 sources, it is rl_resize_terminal() not

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

Hi, First off: Glad that you investigated, this has been bugging me. On 2015-12-14 15:57:22 -0600, Merlin Moncure wrote: > Also, after some experimentation I had better luck with > rl_reset_screen_size() (vs rl_resize_terminal()) that seemed to give > more regular behavior with the prompt. So

Re: [HACKERS] fix for readline terminal size problems when window is resized with open pager

On 2015-12-16 11:21:53 -0500, Tom Lane wrote: > It looks to me like what it's doing is repainting the current line > on the theory that it might be messed up. Since we are, at this > point, presumably *not* in the middle of accepting a command line, > that should be unnecessary but also harmless.

[HACKERS] Experimental evaluation of PostgreSQL's query optimizer

Hi, We have recently performed an experimental evaluation of PostgreSQL's query optimizer. For example, we measured the contributions of cardinality estimation and the cost model on the overall query performance. You can download the resulting paper here:

[HACKERS] A typo in syncrep.c

Hello, I think I found a typo in a comment of syncrep.c. > * acknowledge the commit nor raise ERROR or FATAL. The latter would > - * lead the client to believe that that the transaction aborted, which > * is not true: it's already committed locally. The former is no good The 'that' looks

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On Wed, Dec 16, 2015 at 8:19 AM, Tomas Vondra wrote: > Hi, > > I've reviewed the patch today, after re-reading the whole discussion. Thanks for the review. > The one unsolved issue is what to do with 1e24cf64. My understanding is that > the current patch still

Re: [HACKERS] Passing initially_valid values instead of !skip_validation to StoreRelCheck() in AddRelationNewConstraints()

Updated patch to add this table creation case in regression tests. PFA patch version V3. Regards, Amul Sul transformCheckConstraints-function-to-overrid-not-valid_V3.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Experimental evaluation of PostgreSQL's query optimizer

On 16 December 2015 at 09:51, Viktor Leis wrote: > Hi, > > We have recently performed an experimental evaluation of PostgreSQL's > query optimizer. For example, we measured the contributions of > cardinality estimation and the cost model on the overall query > performance. You

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Wed, Dec 16, 2015 at 8:34 AM, Michael Paquier wrote: > On Mon, Dec 14, 2015 at 8:59 AM, Michael Paquier > wrote: > > On Mon, Dec 14, 2015 at 1:01 AM, Magnus Hagander > wrote: > >> I've applied these two patches now.

Re: [HACKERS] pgbench stats per script & other stuff

It seems also that it would be a good idea to split the patch into two parts: 1) Refactor the code so as the existing test scripts are put under the same umbrella with addScript, adding at the same time the new option -b. 2) Add the weight facility and its related statistics. Sigh. The patch