Re: [HACKERS] PostgreSQL Failback without rebuild

Michael Paquier wrote: > On Fri, Feb 7, 2014 at 3:02 PM, James Sewell > wrote: > >> Node A could get ahead even if it has been shut down cleanly BEFORE the >> promotion? >> I'd always assumed if I shut down the master the slave would be at the same >> point after shutdown >> - is this incorrec

Re: [HACKERS] PostgreSQL Failback without rebuild

On Fri, Feb 7, 2014 at 3:02 PM, James Sewell wrote: > Node A could get ahead even if it has been shut down cleanly BEFORE the > promotion? > I'd always assumed if I shut down the master the slave would be at the > same point after shutdown - is this incorrect? > Yes and no. A node will wait at shu

Re: [HACKERS] Inconsistency between pg_stat_activity and log_duration

On Fri, Feb 7, 2014 at 11:46 AM, Tatsuo Ishii wrote: >> I think that is the probable reason for the above mentioned behaviour. >> As I understand here, the problem is that 'state' of backend is shown as >> active along with 'query' which according to docs (If state is active this >> field >> show

Re: [HACKERS] Inconsistency between pg_stat_activity and log_duration

> I think that is the probable reason for the above mentioned behaviour. > As I understand here, the problem is that 'state' of backend is shown as > active along with 'query' which according to docs (If state is active this > field > shows the currently executing query.) means that query is execu

[HACKERS] Typo in a comment?

In src/backend/storage/freespace/freespace.c, * * MaxFSMRequestSize depends on the architecture and BLCKSZ, but assuming * default 8k BLCKSZ, and that MaxFSMRequestSize is 24 bytes, the categories * look like this * Is "24 bytes" a typo considering that #define MaxFSMRequestSize MaxHeapTu

Re: [HACKERS] PostgreSQL Failback without rebuild

Node A could get ahead even if it has been shut down cleanly BEFORE the promotion? I'd always assumed if I shut down the master the slave would be at the same point after shutdown - is this incorrect? Cheers, James Sewell, PostgreSQL Team Lead / Solutions Architect _

Re: [HACKERS] PostgreSQL Failback without rebuild

On Fri, Feb 7, 2014 at 1:57 PM, James Sewell wrote: > I've just noticed that on PostgreSQL 9.3 I can do the following with a > master node A and a slave node B (as long as I have set > recovery_target_timeline = 'latest'): > >1. Stop Node A >2. Promote Node B >3. Attach Node A as slave

Re: [HACKERS] narwhal and PGDLLIMPORT

OK I can see the error message at PostgreSQL Build Farm Log. I see a similar problem in a simple test case. gcc -DCALLPG=\"import1\" -c export.c -o export1.o dlltool --export-all --output-def export1.def export1.o dlltool --dllname export1.exe --def export1.def --output-lib export1.a dlltool --dl

Re: [HACKERS] Inconsistency between pg_stat_activity and log_duration

On Fri, Feb 7, 2014 at 10:43 AM, Amit Kapila wrote: > On Tue, Feb 4, 2014 at 9:36 AM, Tatsuo Ishii wrote: >> As you can see, at 2014-02-04 12:47:27.210981+09 the query "SELECT >> count(*) FROM pg_catalog.pg_class..." is "active" and it seems still >> running. >> >> On the other side, Here is an e

Re: [HACKERS] Inconsistency between pg_stat_activity and log_duration

On Tue, Feb 4, 2014 at 9:36 AM, Tatsuo Ishii wrote: > As you can see, at 2014-02-04 12:47:27.210981+09 the query "SELECT > count(*) FROM pg_catalog.pg_class..." is "active" and it seems still > running. > > On the other side, Here is an excerpt from PostgreSQL log: > > 21850 2014-02-04 12:47:11.24

Re: [HACKERS] PostgreSQL Failback without rebuild

I've just noticed that on PostgreSQL 9.3 I can do the following with a master node A and a slave node B (as long as I have set recovery_target_timeline = 'latest'): 1. Stop Node A 2. Promote Node B 3. Attach Node A as slave This is sufficient for my needs (I know it doesn't cover a crash

Re: [HACKERS] Row-security on updatable s.b. views

On 02/06/2014 11:11 PM, Tom Lane wrote: > Craig Ringer writes: >> We don't rerun rewrite on plan invalidation. > > Don't we? plancache.c certainly does, in fact it starts from the raw > grammar output. Skipping the rewriter would mean failing to respond > to CREATE OR REPLACE VIEW, for example.

Re: [HACKERS] Retain dynamic shared memory segments for postmaster lifetime

On Thu, Feb 6, 2014 at 3:42 PM, Kyotaro HORIGUCHI wrote: > Hello, I've understood how this works and seems working as > expected. > >> Anyway this is just a test module so if things works for you by >> changing the above way, its fine. However I wonder why its not >> generating .def file for you.

Re: [HACKERS] narwhal and PGDLLIMPORT

(2014/02/05 14:52), Tom Lane wrote: > Craig Ringer writes: >> On 02/05/2014 06:29 AM, Tom Lane wrote: >>> I had been okay with the manual PGDLLIMPORT-sprinkling approach >>> (not happy with it, of course, but prepared to tolerate it) as long >>> as I believed the buildfarm would reliably tell us o

Re: [HACKERS] Recovery inconsistencies, standby much larger than primary

Andres Freund writes: > That reminds me, not that I directly see how it could be responsible, > there's still 20131029011623.gj20...@awork2.anarazel.de ff. around. I > don't think we came to a agreement in that thread how to fix the > problem. Hm, yeah. I'm not sure I believe Heikki's argument t

Re: adt Makefile, was Re: [HACKERS] jsonb and nested hstore

On Fri, Feb 7, 2014 at 1:18 AM, Andrew Dunstan wrote: > > On 02/01/2014 05:20 PM, Andres Freund wrote: >>> >>> diff --git a/src/backend/utils/adt/Makefile >>> b/src/backend/utils/adt/Makefile >>> >index 1ae9fa0..fd93d9b 100644 >>> >--- a/src/backend/utils/adt/Makefile >>> >+++ b/src/backend/utils/

Re: [HACKERS] Recovery inconsistencies, standby much larger than primary

On 2014-02-06 18:42:05 -0500, Tom Lane wrote: > Greg Stark writes: > > On Thu, Feb 6, 2014 at 11:48 PM, Andres Freund > > wrote: > >> That's not necessarily true. If e.g. the buffer mapping would change > >> racily, the result write from the bgwriter could very well end up > >> increasing the fi

Re: [HACKERS] Recovery inconsistencies, standby much larger than primary

Greg Stark writes: > On Thu, Feb 6, 2014 at 11:48 PM, Andres Freund wrote: >> That's not necessarily true. If e.g. the buffer mapping would change >> racily, the result write from the bgwriter could very well end up >> increasing the file size, leaving a hole inbetween its write and the >> origin

Re: [HACKERS] Recovery inconsistencies, standby much larger than primary

On Thu, Feb 6, 2014 at 11:48 PM, Andres Freund wrote: > > That's not necessarily true. If e.g. the buffer mapping would change > racily, the result write from the bgwriter could very well end up > increasing the file size, leaving a hole inbetween its write and the > original size. a) the segment

Re: [HACKERS] mvcc catalo gsnapshots and TopTransactionContext

Andres Freund writes: > On 2014-02-06 16:35:07 -0500, Tom Lane wrote: >> Thoughts? > Let's let it stew a while in master, there certainly are enough > subtleties around this that I'd hesitate to add it to a point release in > the not too far away future. Doesn't seem that urgent to me. But after

Re: [HACKERS] mvcc catalo gsnapshots and TopTransactionContext

I wrote: > (BTW, I see that the CLOBBER_CACHE_ALWAYS members of the buildfarm are > unhappy with the IsTransactionState check in RelationIdGetRelation. > Will look at that ... but it seems to be in initdb which breaks a lot > of these rules anyway, so I think it's probably not significant.) So wha

Re: [HACKERS] Recovery inconsistencies, standby much larger than primary

On 2014-02-06 23:41:19 +0100, Greg Stark wrote: > The problem with the bgwriter being at fault is that from what I can > see the bgwriter will never extend a file. That means the xlog > recovery code must have done it. That means even if the bgwriter came > along and looked at the buffer we just re

Re: [HACKERS] Recovery inconsistencies, standby much larger than primary

On Thu, Feb 6, 2014 at 10:48 PM, Tom Lane wrote: > I had noticed that the WAL records that were mis-replayed seemed to > be bunched pretty close together (two of them even adjacent). Could > you confirm that? If so, it seems like we're looking for some condition > that makes mis-replay fairly pr

Re: [HACKERS] Minor performance improvement in transition to external sort

On 06/02/14 14:22, Robert Haas wrote: On Thu, Feb 6, 2014 at 4:22 AM, Jeremy Harris wrote: On 05/02/14 21:56, Robert Haas wrote: On Tue, Feb 4, 2014 at 5:22 PM, Jeremy Harris wrote: The attached patch replaces the existing siftup method for heapify with a siftdown method. Tested with random

Re: [HACKERS] 'dml' value for log_statement

Sawada Masahiko wrote > Hi all, > > Attaching patch provides new value 'dml' for log_statement. > Currently, The server logs modification statements AND data definition > statements if log_statement is set 'mod'. > So we need to set the 'all' value for log_statement and remove > unnecessary infor

Re: [HACKERS] Minor performance improvement in transition to external sort

On 06/02/14 18:21, Jeff Janes wrote: How big of sets were you sorting in each case? Big enough to go external. The timings and compare-counts given are purely for the heapify stage not the total for the sort, so are constrained by the work_mem not by the sort size per se. I'm limited to wor

Re: [HACKERS] Release schedule for 9.3.3?

On Thu, Feb 6, 2014 at 10:55 PM, Sean Chittenden wrote: > Are there any tentative plans for the 9.3.3 release date? 9.3.2 was released > in December and it's getting close to the two month mark for another micro > release, or at least one seems like one should be right around the corner. Bug f

[HACKERS] Release schedule for 9.3.3?

Are there any tentative plans for the 9.3.3 release date? 9.3.2 was released in December and it’s getting close to the two month mark for another micro release, or at least one seems like one should be right around the corner. It’s a little early, but I haven’t seen any movement or discussion so

Re: [HACKERS] mvcc catalo gsnapshots and TopTransactionContext

On 2014-02-06 16:35:07 -0500, Tom Lane wrote: > > I wonder though, if we couldn't just stop doing the > > RelationReloadIndexInfo() for nailed indexes. > > No; you're confusing nailed indexes with mapped indexes. There are nailed > indexes that aren't on mapped catalogs, see the load_critical_ind

Re: [HACKERS] Recovery inconsistencies, standby much larger than primary

Greg Stark writes: > Both the primary and the standby were 9.1.11 from the get-go. The > database the primary was forked off of was 9.1.10 but as far as I can > tell the primary in the current pair has no problems. > What's worse is we created a new standby from the same base backup and > replaye

Re: [HACKERS] mvcc catalo gsnapshots and TopTransactionContext

Andres Freund writes: > On 2014-02-02 15:16:45 -0500, Tom Lane wrote: >> I've been thinking about this for the past little while, and I believe >> that it's probably okay to have RelationClearRelation leave the relcache >> entry un-rebuilt, but with rd_isvalid = false so it will be rebuilt when >>

Re: [HACKERS] Recovery inconsistencies, standby much larger than primary

On Mon, Feb 3, 2014 at 12:02 AM, Tom Lane wrote: > What version were you running before 9.1.11 exactly? I took a look > through all the diffs from 9.1.9 up to 9.1.11, and couldn't find any > changes that seemed even vaguely related to this. There are some > changes in known-transaction tracking,

[HACKERS] Re: [DOCS] Re: Viability of text HISTORY/INSTALL/regression README files (was Re: [COMMITTERS] pgsql: Document a few more regression test hazards.)

On 02/05/2014 07:27 PM, Robert Haas wrote: > On Tue, Feb 4, 2014 at 11:43 PM, Noah Misch wrote: >>> Right. I mean, a lot of the links say things like "Section 26.2" >>> which obviously makes no sense in a standalone text file. >> >> For s normally displayed that way, text output could emit a URL,

Re: [HACKERS] PoC: Partial sort

Robert Haas writes: > On Thu, Feb 6, 2014 at 3:39 AM, Marti Raudsepp wrote: >> I guess it's because the patch undoes some optimizations in the >> mergejoin planner wrt caching merge clauses and adds a whole lot of >> code to find_mergeclauses_for_pathkeys. In other code paths the >> overhead does

Re: [HACKERS] PoC: Partial sort

On Thu, Feb 6, 2014 at 9:15 PM, Robert Haas wrote: > It may be that having the capability to do a > partial sort makes it seem worth spending more CPU looking for merge > joins, but I'd vote for making any such change a separate patch. Agreed. Alexander, should I work on splitting up the patch i

Re: Fwd: [HACKERS] Proposal: variant of regclass

On Tue, Jan 28, 2014 at 10:38 AM, Yugo Nagata wrote: > I revised the patch. Could you please review this? I didn't test the patch due to the duplicate OID compilation error. But a few things stuck out from the diffs: * You added some unnecessary spaces at the beginning of the linein OpernameGetCa

Re: [HACKERS] PoC: Partial sort

On Thu, Feb 6, 2014 at 3:39 AM, Marti Raudsepp wrote: > On Thu, Feb 6, 2014 at 5:31 AM, Robert Haas wrote: >> Hmm, sounds a little steep. Why is it so expensive? I'm probably >> missing something here, because I would have thought that planner >> support for partial sorts would consist mostly o

Re: [HACKERS] extension_control_path

On Feb 6, 2014, at 9:14 AM, Greg Stark wrote: > Installing into /usr/local is a global system change. Only root should > be able to do that and any user that can do that can easily acquire > root privileges. I agree with you, but I don’t think the Homebrew folks do. Or at least their current im

[HACKERS] 'dml' value for log_statement

Hi all, Attaching patch provides new value 'dml' for log_statement. Currently, The server logs modification statements AND data definition statements if log_statement is set 'mod'. So we need to set the 'all' value for log_statement and remove unnecessary information if we would like to log only

Re: [HACKERS] Minor performance improvement in transition to external sort

On Tue, Feb 4, 2014 at 2:22 PM, Jeremy Harris wrote: > The attached patch replaces the existing siftup method for heapify with > a siftdown method. Tested with random integers it does 18% fewer > compares and takes 10% less time for the heapify, over the work_mem > range 1024 to 1048576. > Thank

Re: [HACKERS] extension_control_path

On Thu, Feb 6, 2014 at 5:49 PM, David E. Wheeler wrote: > On Feb 6, 2014, at 6:51 AM, Greg Stark wrote: > >> Homebrew sounds kind of confused. Having a non-root user have access >> to make global system changes sounds like privilege escalation >> vulnerability by design. > > Well, the point is th

Re: [HACKERS] jsonb and nested hstore

On Feb 5, 2014, at 3:59 PM, Andrew Dunstan wrote: > I got a slightly earlier start ;-) For people wanting to play along, here's > what this change looks like: > Man I love seeing all that read. :-) D -- S

Re: adt Makefile, was Re: [HACKERS] jsonb and nested hstore

On 02/06/2014 11:38 AM, Alvaro Herrera wrote: Andrew Dunstan wrote: This whole list is a mess, and we don't even have all the range_types files following each other. Worth cleaning up? I'm actually wondering if it might be worth having some subgroups of object files and then combining them i

Re: [HACKERS] extension_control_path

On Feb 6, 2014, at 7:32 AM, Stephen Frost wrote: > The end-admin would have to modify the system-installed postgresql.conf > anyway to enable this other directory. David wasn't suggesting that > Homebrew *should* be able to do so, he was pointing out that it *can't*, > which all makes sense imv.

Re: [HACKERS] extension_control_path

On Feb 6, 2014, at 6:51 AM, Greg Stark wrote: > Homebrew sounds kind of confused. Having a non-root user have access > to make global system changes sounds like privilege escalation > vulnerability by design. Well, the point is that it *doesn’t* make global system changes. I got an error on OS

Re: adt Makefile, was Re: [HACKERS] jsonb and nested hstore

Andrew Dunstan wrote: > This whole list is a mess, and we don't even have all the > range_types files following each other. > > Worth cleaning up? > > I'm actually wondering if it might be worth having some subgroups of > object files and then combining them into $OBJS. Doesn't the MSVC build s

Re: adt Makefile, was Re: [HACKERS] jsonb and nested hstore

Andrew Dunstan writes: > On 02/01/2014 05:20 PM, Andres Freund wrote: >> Odd, most OBJS lines are kept in alphabetical order, but that doesn't >> seem to be the case here. > This whole list is a mess, and we don't even have all the range_types > files following each other. > Worth cleaning up?

Re: [HACKERS] Small GIN optimizations (after 9.4)

i think there is one more thing which would be really good in GIN and which would solve a ton of issues. atm GIN entries are sorted by item pointer. if we could sort them by a "column" it would fix a couple of real work issues such as ... SELECT ... FROM foo WHERE "tsearch_query" ORDER B

adt Makefile, was Re: [HACKERS] jsonb and nested hstore

On 02/01/2014 05:20 PM, Andres Freund wrote: diff --git a/src/backend/utils/adt/Makefile b/src/backend/utils/adt/Makefile >index 1ae9fa0..fd93d9b 100644 >--- a/src/backend/utils/adt/Makefile >+++ b/src/backend/utils/adt/Makefile >@@ -32,7 +32,8 @@ OBJS = acl.o arrayfuncs.o array_selfuncs.o arra

Re: [HACKERS] extension_control_path

* Greg Stark (st...@mit.edu) wrote: > On Tue, Feb 4, 2014 at 6:07 PM, David E. Wheeler > wrote: > > The install failed, of course, because extensions want to install in > > $PGROOT/share/extensions. > > Homebrew sounds kind of confused. Having a non-root user have access > to make global system

Re: [HACKERS] updated emacs configuration

On 2014-02-06 10:24:34 -0500, Tom Lane wrote: > Andres Freund writes: > > Nah, not for that ;). I mean I haven't seen any replacement for pgindent > > that generates equivalent variable indentations. > > Seems odd. I thought netbsd's indent was pretty much the granddaddy of > them all --- so you

Re: [HACKERS] open and close columns in the NEW record not allowed

On Thu, Feb 06, 2014 at 04:21:41PM +0100, Rafael Martinez Guerrero wrote: > On Thu, 2014-02-06 at 07:11 -0800, Adrian Klaver wrote: > > On 02/06/2014 06:35 AM, Rafael Martinez Guerrero wrote: > > > > We think the behavior should be consistent, either it is allow to use > > > them or not, but not l

Re: [HACKERS] open and close columns in the NEW record not allowed

On Thu, 2014-02-06 at 07:11 -0800, Adrian Klaver wrote: > On 02/06/2014 06:35 AM, Rafael Martinez Guerrero wrote: > > We think the behavior should be consistent, either it is allow to use > > them or not, but not like it is today. > > > > " As a general rule, if you get spurious parser errors for

Re: [HACKERS] updated emacs configuration

Andres Freund writes: > Nah, not for that ;). I mean I haven't seen any replacement for pgindent > that generates equivalent variable indentations. Seems odd. I thought netbsd's indent was pretty much the granddaddy of them all --- so you'd expect newer tools to be able to replicate that style.

Re: [HACKERS] updated emacs configuration

On 2014-02-06 10:04:54 -0500, Tom Lane wrote: > Andres Freund writes: > > What I haven't seen in any tool yet is something to resemble our > > indentation style for variable declarations. Do we feel that's a > > dealbreaker for any tool? > > Well, we're unlikely to change pgindent's rules to conf

Re: [HACKERS] open and close columns in the NEW record not allowed

Rafael Martinez Guerrero writes: > The problem is that pl/pgsql does not accept open and close as column > names when used in the NEW record in a trigger function. Yup. Those words (and other words that can start a plpgsql statement) are reserved so far as plpgsql is concerned. > This page: > h

Re: [HACKERS] open and close columns in the NEW record not allowed

On 02/06/2014 06:35 AM, Rafael Martinez Guerrero wrote: Hello One of our users is having a problem with a trigger in a system running postgresql 9.3. The problem is that pl/pgsql does not accept open and close as column names when used in the NEW record in a trigger function. This page: http:/

Re: [HACKERS] Row-security on updatable s.b. views

Craig Ringer writes: > We don't rerun rewrite on plan invalidation. Don't we? plancache.c certainly does, in fact it starts from the raw grammar output. Skipping the rewriter would mean failing to respond to CREATE OR REPLACE VIEW, for example. regards, tom lane -- S

Re: [HACKERS] updated emacs configuration

Andres Freund writes: > What I haven't seen in any tool yet is something to resemble our > indentation style for variable declarations. Do we feel that's a > dealbreaker for any tool? Well, we're unlikely to change pgindent's rules to conform to the behavior of some random emacs mode, if that's w

Re: [HACKERS] updated emacs configuration

Andres Freund wrote: > What I haven't seen in any tool yet is something to resemble our > indentation style for variable declarations. Do we feel that's a > dealbreaker for any tool? I find our style more aesthetically pleasing than any other I've seen; but anyway the changes if we used a tool th

Re: [HACKERS] extension_control_path

On Tue, Feb 4, 2014 at 6:07 PM, David E. Wheeler wrote: > The install failed, of course, because extensions want to install in > $PGROOT/share/extensions. Homebrew sounds kind of confused. Having a non-root user have access to make global system changes sounds like privilege escalation vulnerabi

[HACKERS] open and close columns in the NEW record not allowed

Hello One of our users is having a problem with a trigger in a system running postgresql 9.3. The problem is that pl/pgsql does not accept open and close as column names when used in the NEW record in a trigger function. This page: http://www.postgresql.org/docs/9.3/static/sql-keywords-appendix.

Re: [HACKERS] Row-security on updatable s.b. views

On 02/06/2014 10:19 PM, Craig Ringer wrote: > On 02/06/2014 12:43 PM, Craig Ringer wrote: >> 1. Try (again) to do row-security in the rewriter. This was previously >> impossible because of the definition of row-security behaviour around >> inheritance, but with the simplified inheritance model now

Re: [HACKERS] Minor performance improvement in transition to external sort

On Thu, Feb 6, 2014 at 4:22 AM, Jeremy Harris wrote: > On 05/02/14 21:56, Robert Haas wrote: >> On Tue, Feb 4, 2014 at 5:22 PM, Jeremy Harris wrote: >>> The attached patch replaces the existing siftup method for heapify with >>> a siftdown method. Tested with random integers it does 18% fewer >>>

Re: [HACKERS] Row-security on updatable s.b. views

On 02/06/2014 12:43 PM, Craig Ringer wrote: > 1. Try (again) to do row-security in the rewriter. This was previously > impossible because of the definition of row-security behaviour around > inheritance, but with the simplified inheritance model now proposed I > think it's possible. Thanks to the

Re: [HACKERS] updated emacs configuration

On 2013-07-21 02:06:02 +0100, Greg Stark wrote: > On Thu, Jun 27, 2013 at 10:31 PM, Tom Lane wrote: > > > > AFAIR, no one has ever done a serious comparison to anything except GNU > > indent, and (at least at the time) it seemed to have bugs as bad as > > pgindent's, just different ones. I'm cert

Re: [HACKERS] updated emacs configuration

On 7/20/13, 9:06 PM, Greg Stark wrote: > In theory this tool is promising though since it works by looking at > the llvm bytecode to determine what the real syntax is. It should be > able to handle the typedef issues we have with most of the the tools. Since clang-format has no options to specify

Re: [HACKERS] Retain dynamic shared memory segments for postmaster lifetime

On Thu, Feb 6, 2014 at 4:10 PM, Kyotaro HORIGUCHI wrote: > Hello, let me say in passing, > >> However I wonder why its not generating .def file for you. > > Is the 'it' is Visual Studio IDE or CL? Mmm, as far as I know > .def file is a stuff that programmers should write by their hands > as a matt

Re: [HACKERS] Row-security on updatable s.b. views

On 02/06/2014 04:54 PM, Yeb Havinga wrote: > On 2014-02-06 05:43, Craig Ringer wrote: >> Based on Tom's objections, another approach is presented in >> rls-9.4-upd-sb-views-v5 on g...@github.com:ringerc/postgres.git . The >> Query node is used to record the recursive expansion parent list >> inste

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Wed, Feb 5, 2014 at 8:56 PM, Amit Kapila wrote: > On Wed, Feb 5, 2014 at 5:13 PM, Heikki Linnakangas > wrote: >> On 02/05/2014 07:54 AM, Amit Kapila wrote: >> >> That's not the worst case, by far. >> >> First, note that the skipping while scanning new tuple is only performed in >> the first lo

Re: [HACKERS] Add CREATE support to event triggers

On Thu, Feb 6, 2014 at 12:08 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Feb 5, 2014 at 2:26 PM, Alvaro Herrera >> wrote: Then again, why is the behavior of schema-qualifying absolutely everything even desirable? > >>> Well, someone could create a collation in another schema

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Thu, Feb 6, 2014 at 9:13 AM, Amit Kapila wrote: > On Wed, Feb 5, 2014 at 8:50 PM, Heikki Linnakangas > wrote: >> On 02/05/2014 04:48 PM, Amit Kapila wrote: >>> >>> I have done one test where there is a large suffix match, but >>> not large enough that it can compress more than 75% of string, >

[HACKERS] Small GIN optimizations (after 9.4)

While hacking on the GIN patches, I've come up with a few different ideas for improving performance. It's too late for 9.4, but I'll list them here if someone wants to work on them later: * Represent ItemPointers as uint64's, to speed up comparisons. ginCompareItemPointers is inlined into only

Re: [HACKERS] GIN improvements part2: fast scan

On Thu, Feb 6, 2014 at 2:21 PM, Heikki Linnakangas wrote: > On 02/05/2014 12:42 PM, Alexander Korotkov wrote: > >> Attached patch is "light" version of fast scan. It does extra consistent >> function calls only on startScanKey, no extra calls during scan of the >> index. >> It finds subset of rare

Re: [HACKERS] Retain dynamic shared memory segments for postmaster lifetime

Hello, let me say in passing, > However I wonder why its not generating .def file for you. Is the 'it' is Visual Studio IDE or CL? Mmm, as far as I know .def file is a stuff that programmers should write by their hands as a matter of course. I've found no way to automatically generate .def file

Re: [HACKERS] GIN improvements part2: fast scan

On 02/05/2014 12:42 PM, Alexander Korotkov wrote: Attached patch is "light" version of fast scan. It does extra consistent function calls only on startScanKey, no extra calls during scan of the index. It finds subset of rarest entries absence of which guarantee false consistent function result.

Re: [HACKERS] Retain dynamic shared memory segments for postmaster lifetime

Hello, I've understood how this works and seems working as expected. > Anyway this is just a test module so if things works for you by > changing the above way, its fine. However I wonder why its not > generating .def file for you. Surely. Getting back on topic, using dsm_keep_segment, I saw pos

Re: [HACKERS] GiST support for inet datatypes

2014-01-19 12:10, Emre Hasegeli : > 2014-01-19 Andreas Karlsson : > >> I am a bit suspicious about your memcmp based optimization in bitncommon, >> but it could be good. Have you benchmarked it compared to doing the same >> thing with a loop? > > I did, when I was writing that part. I will be happy

Re: [HACKERS] Minor performance improvement in transition to external sort

On 05/02/14 21:56, Robert Haas wrote: On Tue, Feb 4, 2014 at 5:22 PM, Jeremy Harris wrote: The attached patch replaces the existing siftup method for heapify with a siftdown method. Tested with random integers it does 18% fewer compares and takes 10% less time for the heapify, over the work_mem

Re: [HACKERS] [doc patch] extra_float_digits and casting from real to numeric

Re: Robert Haas 2014-02-05 > >> 0, the output is the same on every platform > >> supported by PostgreSQL. Increasing it will produce output that > >> more accurately represents the stored value, but may be unportable. > >> + Casts to other numeric datatypes and the

Re: [HACKERS] Patch: show xid and xmin in pg_stat_activity and pg_stat_replication

On 2014-02-05 13:26:15 -0500, Robert Haas wrote: > On Wed, Feb 5, 2014 at 1:21 PM, Tom Lane wrote: > > Robert Haas writes: > >> It feels weird to me that the new columns are called transactionid and > >> xmin. Why not xid and xmin? > > > > Actually the part of that that bothers me is "xmin", whi

Re: [HACKERS] Row-security on updatable s.b. views

On 2014-02-06 05:43, Craig Ringer wrote: Based on Tom's objections, another approach is presented in rls-9.4-upd-sb-views-v5 on g...@github.com:ringerc/postgres.git . The Query node is used to record the recursive expansion parent list instead, and copying is avoided. Cannot fetch or clone. g

Re: [HACKERS] PoC: Partial sort

On Thu, Feb 6, 2014 at 5:31 AM, Robert Haas wrote: > Hmm, sounds a little steep. Why is it so expensive? I'm probably > missing something here, because I would have thought that planner > support for partial sorts would consist mostly of considering the same > sorts we consider today, but with t

Re: [HACKERS] Misaligned BufferDescriptors causing major performance problems on AMD

On 2014-02-05 12:36:42 -0500, Robert Haas wrote: > >> It may well be that your proposal is spot on. But I'd like to see some > >> data-structure-by-data-structure measurements, rather than assuming that > >> alignment must be a good thing. > > > > I am fine with just aligning BufferDescriptors pro