Re: [HACKERS] ICU integration

On Wed, Feb 15, 2017 at 9:17 PM, Peter Eisentraut wrote: > I have changed it to use ucol_nextSortKeyPart() when appropriate. I think it would be fine if the second last argument was "sizeof(Datum)", not "Min(sizeof(Datum), sss->buflen2)" here: > +

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

Hi, Just to summarize what you could read between the lines in the previous mail: From a higher level POV the design here makes sense to me, I do however think there's a good chunk of code-level improvements needed. Regards, Andres -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Parallel Index Scans

On Thu, Feb 16, 2017 at 12:27 AM, Robert Haas wrote: > On Wed, Feb 15, 2017 at 1:39 PM, Robert Haas wrote: >> On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila >> wrote:> >>> support related patch. In anycase, to avoid

Re: [HACKERS] Parallel Append implementation

On Wed, Feb 15, 2017 at 6:40 PM, Robert Haas wrote: > On Wed, Feb 15, 2017 at 4:43 AM, Amit Khandekar > wrote: >>> On 14 February 2017 at 22:35, Robert Haas wrote: For example, suppose that I have a scan of two

Re: [HACKERS] case_preservation_and_insensitivity = on

Joel Jacobson writes: > Case Preservation + Case Insensitivity = A good combination > Thoughts? Have you read any of our innumerable previous discussions about this? The last one was barely a month ago, cf

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

Hi, On 2017-02-13 23:57:00 +1300, Thomas Munro wrote: > Here's a new version to fix the problems reported by Rafia above. The > patch descriptions are as before but it starts from 0002 because 0001 > was committed as 7c5d8c16 (thanks, Andres). FWIW, I'd appreciate if you'd added a short commit

[HACKERS] case_preservation_and_insensitivity = on

Hi hackers, "A system that is not case-preserving is necessarily case-insensitive, but it is possible and common for a system to be case-insensitive, yet case-preserving" [1] Imagine if you could turn on a GUC that would turn PostgreSQL into such a system, where the case would be preserved by

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Wed, 15 Feb 2017 15:23:00 -0500 Robert Haas wrote: > +ereport(WARNING, > +(errcode(ERRCODE_INTERNAL_ERROR), > + errmsg("corrupted data found in \"%s\"", > +LOG_METAINFO_DATAFILE))); > >

Re: [HACKERS] Patch to implement pg_current_logfile() function

"Karl O. Pinc" writes: > On a different topic, I pulled from master and now > I see that git finds the following untracked: > src/bin/pg_basebackup/pg_receivexlog > src/bin/pg_resetxlog/ > src/bin/pg_xlogdump/ Those got renamed, cf

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

Simon Riggs wrote: > Please persuade us with measurements that allowing this impact on > ANALYZE would really improve performance at least in your case, and > also examine the effect of this on the accuracy and usefulness of the > gathered statistics. I explain

Re: [HACKERS] Documentation improvements for partitioning

On 2017/02/16 2:08, Robert Haas wrote: > On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera > wrote: >> I think new-style partitioning is supposed to consider each partition as >> an implementation detail of the table; the fact that you can manipulate >> partitions

Re: [HACKERS] Parallel Index-only scan

I reviewed the patch. Overall it looks fine to me. One comment, >- if (index->amcanparallel && >- !index_only_scan && >+ if ((index->amcanparallel || >+ index_only_scan) && Why do we need to check for index_only_scan in the above condition. IIUC,

Re: [HACKERS] ICU integration

On 1/31/17 16:59, Thomas Munro wrote: > I assume (but haven't checked) that ucol_nextSortKeyPart accesses only > the start of the string via the UCharIterator passed in, unless you > have the rare reverse-accent-sort feature enabled (maybe used only in > fr_CA, it looks like it is required to scan

Re: [HACKERS] Parallel Append implementation

On 15 February 2017 at 18:40, Robert Haas wrote: > On Wed, Feb 15, 2017 at 4:43 AM, Amit Khandekar > wrote: >>> On 14 February 2017 at 22:35, Robert Haas wrote: For example, suppose that I have a scan of two children,

Re: [HACKERS] SCRAM authentication, take three

On Wed, Feb 15, 2017 at 8:28 PM, Heikki Linnakangas wrote: > Ah, found it. It was because of this change: > > Having two error codes with the same SQLSTATE is not cool, and tripped the > assertion in PL/python. I removed the new error code, it was only used in > one place, and

Re: [HACKERS] ICU integration

On Wed, Feb 15, 2017 at 9:17 PM, Peter Eisentraut wrote: >> Clearly when you upgrade your system from (say) Debian 8 to Debian 9 >> and the ICU major version changes we expect to have to REINDEX, but >> does anyone know if such data changes are ever pulled into

Re: [HACKERS] UPDATE of partition key

On 2017/02/16 15:50, Amit Khandekar wrote: > On 15 February 2017 at 20:26, David Fetter wrote: >> When an UPDATE can't happen, there are often ways to hint at >> what went wrong and how to correct it. Violating a uniqueness >> constraint would be one example. >> >> When an

Re: [HACKERS] DROP SUBSCRIPTION and ROLLBACK

On Thu, Feb 16, 2017 at 7:52 AM, Petr Jelinek wrote: > On 15/02/17 06:43, Masahiko Sawada wrote: >> On Tue, Feb 14, 2017 at 1:13 AM, Fujii Masao wrote: >>> On Mon, Feb 13, 2017 at 4:05 PM, Masahiko Sawada >>> wrote:

Re: [HACKERS] UPDATE of partition key

On 15 February 2017 at 20:26, David Fetter wrote: > When an UPDATE can't happen, there are often ways to hint at > what went wrong and how to correct it. Violating a uniqueness > constraint would be one example. > > When an UPDATE can't happen and the depth of the subtree is a

Re: [HACKERS] increasing the default WAL segment size

Andres Freund writes: > On 2017-02-15 22:46:38 -0300, Alvaro Herrera wrote: >> Now that we've renamed "xlog" to "wal" in user-facing elements, I think >> we should strive to use the name "wal" internally too in new code, not >> "xlog" anymore. This patch introduces several

Re: [HACKERS] SCRAM authentication, take three

On 02/09/2017 09:33 AM, Michael Paquier wrote: On Tue, Feb 7, 2017 at 11:28 AM, Michael Paquier wrote: Yes, I am actively working on this one now. I am trying to come up first with something in the shape of an extension to begin with, and get a patch out of it. That

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

Michael Paquier wrote: > On Wed, Feb 15, 2017 at 5:32 PM, Simon Riggs wrote: > > Please persuade us with measurements that allowing this impact on > > ANALYZE would really improve performance at least in your case, and > > also examine the effect of this on the accuracy and

Re: [HACKERS] Bug in to_timestamp().

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed Review of v7 patch: - Patch applies to the top of master HEAD

Re: [HACKERS] SCRAM authentication, take three

On Wed, Feb 15, 2017 at 7:58 PM, Heikki Linnakangas wrote: > On 02/09/2017 09:33 AM, Michael Paquier wrote: >> Now regarding the shape of the implementation for SCRAM, we need one >> thing: a set of routines in src/common/ to build decompositions for a >> given UTF-8 string with

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On Wed, Feb 15, 2017 at 12:03 PM, Seki, Eiji wrote: > Amit Kapila wrote: >> How will you decide just based on oldest xmin whether the tuple is visible >> or not? How will you take decisions about tuples which have xmax set? > > In our use case, GetOldestXmin is used by

Re: [HACKERS] SCRAM authentication, take three

On 02/07/2017 04:20 AM, Michael Paquier wrote: On Tue, Feb 7, 2017 at 3:12 AM, Aleksander Alekseev wrote: No, I'm afraid `make distclean` doesn't help. I've re-checked twice. Hm. I can see the failure on macos and python2 builds as well with the set of patches

Re: [HACKERS] Parallel Index Scans

On Wed, Feb 15, 2017 at 2:04 AM, Robert Haas wrote: > On Tue, Feb 14, 2017 at 12:48 PM, Robert Haas wrote: >> That sounds way better. > > Here's an updated patch. Please review my changes, which include: > > * Various comment updates. 1. + *

Re: [HACKERS] Parallel bitmap heap scan

On Tue, Feb 14, 2017 at 10:18 PM, Robert Haas wrote: > Thanks, the external interface to this looks much cleaner now. > Scrutinizing the internals: Thanks for the comments, I am working on these. I have few doubts for some of the comments. > I suggest removing both

Re: [HACKERS] Parallel Index Scans

On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila wrote: > Here second part of the comment (but have not yet advanced ..) seems > to be slightly misleading because this state has nothing to do with > the advancement of scan keys. > > I have not changed this because I am not

Re: [HACKERS] GUC for cleanup indexes threshold.

On Wed, Feb 15, 2017 at 4:39 PM, Ideriha, Takeshi wrote: > Hi, I tried regression test and found some errors concerning brin and gin, > though I didn't look into this. > > Here's a log: > > *** /home/ideriha/postgres-master/src/test/regress/expected/brin.out >

Re: [HACKERS] Parallel Append implementation

> On 14 February 2017 at 22:35, Robert Haas wrote: >> For example, suppose that I have a scan of two children, one >> of which has parallel_workers of 4, and the other of which has >> parallel_workers of 3. If I pick parallel_workers of 7 for the >> Parallel Append, that's

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On 14 February 2017 at 06:19, Seki, Eiji wrote: > In our benchmark, we found that waiting an ANALYZE process created by > autovacuum daemon often has a significant impact to the performance although > the waited process do only reading as to the table. ... > I'm not

Re: [HACKERS] Should we cacheline align PGXACT?

Hi! On Mon, Feb 13, 2017 at 8:02 PM, Ashutosh Sharma wrote: > I too have performed benchmarking of this patch on a large machine > (with 128 CPU(s), 520GB RAM, intel x86-64 architecture) and would like > to share my observations for the same (Please note that, as I had to

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On Wed, Feb 15, 2017 at 5:32 PM, Simon Riggs wrote: > Please persuade us with measurements that allowing this impact on > ANALYZE would really improve performance at least in your case, and > also examine the effect of this on the accuracy and usefulness of the > gathered

Re: [HACKERS] SERIALIZABLE with parallel query

On Wed, Nov 9, 2016 at 10:51 AM, Thomas Munro wrote: > Need to audit predicate.c for cases where > MySerializableXact might be modified without suitable locking, The only thing I see along those lines is that CheckForSerializableConflictOut() and

Re: [HACKERS] Documentation improvements for partitioning

Noticed some typos in the documentation. Here's patch to correct those. Sorry, if it has been already taken care of. On Wed, Feb 15, 2017 at 10:01 AM, Robert Haas wrote: > On Mon, Feb 13, 2017 at 5:57 AM, Amit Langote > wrote: >> On

Re: [HACKERS] SERIALIZABLE with parallel query

On Wed, Nov 9, 2016 at 12:34 PM, Peter Geoghegan wrote: > On Tue, Nov 8, 2016 at 1:51 PM, Thomas Munro > wrote: >> Currently we don't generate parallel plans in SERIALIZABLE. What >> problems need to be solved to be able to do that? > > FWIW,

Re: [HACKERS] Sum aggregate calculation for single precsion real

On Tue, Feb 14, 2017 at 11:45 PM, Tom Lane wrote: > You could perhaps make an argument that sum(float4) would have less risk > of overflow if it accumulated in and returned float8, but frankly that > seems a bit thin. I think that's more or less the argument Konstantin is in

Re: [HACKERS] Parallel Append implementation

On Wed, Feb 15, 2017 at 4:43 AM, Amit Khandekar wrote: >> On 14 February 2017 at 22:35, Robert Haas wrote: >>> For example, suppose that I have a scan of two children, one >>> of which has parallel_workers of 4, and the other of which has >>>

Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?

On Wed, Feb 15, 2017 at 12:24 AM, Joshua Chamberlain wrote: > Hello, > > (I'm posting to hackers since I got no response on the general list.) > > I use Postgres + PostGIS quite heavily, and recently have been taking full > advantage of the new parallelism in 9.6. I'm now running

Re: [HACKERS] SERIALIZABLE with parallel query

On Tue, Nov 8, 2016 at 4:51 PM, Thomas Munro wrote: > Currently we don't generate parallel plans in SERIALIZABLE. What > problems need to be solved to be able to do that? I'm probably > steamrolling over a ton of subtleties and assumptions here, but it > occurred

Re: [HACKERS] Documentation improvements for partitioning

On Wed, Feb 15, 2017 at 4:26 AM, Ashutosh Bapat wrote: > Noticed some typos in the documentation. Here's patch to correct > those. Sorry, if it has been already taken care of. Thanks. That is indeed nonstandard capitalization. Committed. -- Robert Haas

Re: [HACKERS] Parallel Append implementation

On Wed, Feb 15, 2017 at 2:33 AM, Amit Khandekar wrote: > The only reason I combined the soft limit and the hard limit is > because it is not necessary to have two different fields. But of > course this is again under the assumption that allocating more than >

Re: [HACKERS] exposing wait events for non-backends (was: Tracking wait event for latches)

Hello everyone, As discussed in this thread, I've attached a set of patches to show auxiliary processes, autovacuum launcher and bgworker along with other backends in pg_stat_activity. For now, I've extended BackendStatusArray to store auxiliary processes. Backends use slots indexed in the range

Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?

Hi, On 2017-02-15 08:48:44 -0500, Robert Haas wrote: > We got rid of the major existing use of page locks in > 6d46f4783efe457f74816a75173eb23ed8930020, which extirpated them from > hash indexes, and I was kind of hoping they could go away altogether, > but we can't do that as long as GIN is

Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?

All, * Andres Freund (and...@anarazel.de) wrote: > On 2017-02-15 08:48:44 -0500, Robert Haas wrote: > > The other way of fixing this problem is to have each worker generate a > > subset of the tuples and funnel them all back to the leader through a > > Gather node; the leader then does all the

Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?

On February 15, 2017 5:20:20 PM PST, Stephen Frost wrote: >In many cases, I expect this would work just as well, if not better, >than trying to actually do writes in parallel. Why? IPCing tuples around is quite expensive. Or do you mean because it'll be more suitable

Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?

Andres, * Andres Freund (and...@anarazel.de) wrote: > On February 15, 2017 5:20:20 PM PST, Stephen Frost wrote: > >In many cases, I expect this would work just as well, if not better, > >than trying to actually do writes in parallel. > > Why? IPCing tuples around is quite

Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?

On 2017-02-15 20:28:43 -0500, Stephen Frost wrote: > Andres, > > * Andres Freund (and...@anarazel.de) wrote: > > On February 15, 2017 5:20:20 PM PST, Stephen Frost > > wrote: > > >In many cases, I expect this would work just as well, if not better, > > >than trying to

Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-02-15 20:28:43 -0500, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > On February 15, 2017 5:20:20 PM PST, Stephen Frost > > > wrote: > > > >In many cases, I expect this would work just

Re: [HACKERS] CREATE TABLE with parallel workers, 10.0?

On 2017-02-15 20:35:16 -0500, Stephen Frost wrote: > Perhaps, but until we've got a system worked out for having the workers > do the writes, we aren't getting anything. Being able to have the > leader do the writes based on the tuples fed back from the workers is > clearly better than nothing.

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Mon, Feb 13, 2017 at 10:22 AM, Amit Kapila wrote: > As discussed, attached are refactoring patches and a patch to enable > WAL for the hash index on top of them. Thanks. I think that the refactoring patches shouldn't add START_CRIT_SECTION() and END_CRIT_SECTION()

Re: [HACKERS] Documentation improvements for partitioning

On 2017/02/15 13:31, Robert Haas wrote: > On Mon, Feb 13, 2017 at 5:57 AM, Amit Langote > wrote: >> On 2017/02/13 14:21, Amit Langote wrote: >>> On 2017/02/10 19:19, Simon Riggs wrote: * The OID inheritance needs work - you shouldn't need to specify a

Re: [HACKERS] increasing the default WAL segment size

Now that we've renamed "xlog" to "wal" in user-facing elements, I think we should strive to use the name "wal" internally too in new code, not "xlog" anymore. This patch introduces several variables, macros, functions that ought to change names now -- XLogSegmentOffset should be WALSegmentOffset

Re: [HACKERS] increasing the default WAL segment size

On Wed, Feb 15, 2017 at 8:46 PM, Alvaro Herrera wrote: > Now that we've renamed "xlog" to "wal" in user-facing elements, I think > we should strive to use the name "wal" internally too in new code, not > "xlog" anymore. This patch introduces several variables, macros, >

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On Wed, Feb 15, 2017 at 11:35 PM, Amit Kapila wrote: > On Wed, Feb 15, 2017 at 12:03 PM, Seki, Eiji > wrote: > > Amit Kapila wrote: > >> How will you decide just based on oldest xmin whether the tuple is > visible or not? How will you take

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

On Thu, Feb 16, 2017 at 1:08 AM, Robert Haas wrote: > Great, thanks! This looks good to me, so committed. Thanks. > Is there any > chance you can use your amazing TAP-test-creation powers to do some > automated testing of this feature? For example, maybe we could at >

Re: [HACKERS] increasing the default WAL segment size

On 2017-02-15 22:46:38 -0300, Alvaro Herrera wrote: > Now that we've renamed "xlog" to "wal" in user-facing elements, I think > we should strive to use the name "wal" internally too in new code, not > "xlog" anymore. This patch introduces several variables, macros, > functions that ought to

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Sat, Feb 4, 2017 at 2:45 PM, Peter Geoghegan wrote: > It might just have been that the table was too small to be an > effective target for parallel sequential scan with so many workers, > and so a presorted best case CREATE INDEX, which isn't that different, > also fails to see

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On Thu, Feb 16, 2017 at 10:48 AM, Haribabu Kommi wrote: > Because of the above reason, we need a new API or some change in API > to provide the Oldest xmin by ignoring the ANALYZE transactions, so that > it will reduce the size of WOS and improves the VCI query

Re: [HACKERS] Reporting xmin from VACUUMs

Accidentally sent o--list. On 2/14/17 12:57 PM, Jim Nasby wrote: On 2/13/17 12:36 AM, Masahiko Sawada wrote: It seems sensible to me to do something like this. We already report a lot of other fine details, so what's one more? And it could be useful. Also, I've been proposing to report the

Re: [HACKERS] Add doc advice about systemd RemoveIPC

On 2/14/17 11:49 AM, Magnus Hagander wrote: > + > +If systemd is in use, some care must be > taken > +that IPC resources (shared memory and semaphores) are not prematurely > +removed by the operating system. This is especially of concern when > +installing PostgreSQL from

[HACKERS] error handling in RegisterBackgroundWorker

If RegisterBackgroundWorker() (the non-dynamic kind that is only loadable from shared_preload_libraries) fails to register the worker, it writes a log message and proceeds, ignoring the registration request. I think that is a mistake, it should be a hard error. The only way in practice to fix

Re: [HACKERS] Should we cacheline align PGXACT?

Robert Haas writes: > On Mon, Feb 13, 2017 at 11:07 AM, Alvaro Herrera > wrote: >> It seems to me that Andres comments here were largely ignored: >> https://www.postgresql.org/message-id/20160822021747.u5bqx2xwwjzac...@alap3.anarazel.de >> He was

Re: [HACKERS] pg_basebackup -R

On Tue, Feb 14, 2017 at 11:36 PM, Michael Paquier wrote: > On Wed, Feb 15, 2017 at 2:38 AM, Robert Haas wrote: >> On Thu, Feb 9, 2017 at 9:40 PM, Michael Paquier >> wrote: >>> In short, I'd like to think that we should

Re: [HACKERS] [PATCH] Fix pg_proc comment grammar

On Wed, Feb 15, 2017 at 10:40 AM, David Christensen wrote: > Fixes some DESCR() grammar mistakes introduced by the xlog -> wal changes. Thanks, David! Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] Sum aggregate calculation for single precsion real

On Wed, Feb 15, 2017 at 9:52 AM, Robert Haas wrote: > On Tue, Feb 14, 2017 at 11:45 PM, Tom Lane wrote: >> You could perhaps make an argument that sum(float4) would have less risk >> of overflow if it accumulated in and returned float8, but frankly that

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Wed, 15 Feb 2017 15:23:00 -0500 Robert Haas wrote: > + errhint("The supported log formats are > \"stderr\"" > +" and \"csvlog\"."))); > > I think our preferred style is not to break strings across lines like >

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Fri, Jan 20, 2017 at 2:09 AM, Michael Paquier wrote: > Okay I just did it. At the same time the check for ferror is not > necessary as fgets() returns NULL on an error as well so that's dead > code. I have also removed the useless call to FreeFile(). diff --git

Re: [HACKERS] operator_precedence_warning vs make installcheck

On Wed, Feb 15, 2017 at 11:47 AM, Tom Lane wrote: > I wrote: > > We could possibly prevent the difference by having exprLocation look > > through such nodes. I'm not sure offhand if there are cases where > > that would be worse than before. We've definitely made some other

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Wed, Feb 15, 2017 at 12:24 PM, Robert Haas wrote: > On Tue, Jan 24, 2017 at 4:32 AM, Peter Moser wrote: > >> Using common terms such as ALIGN and NORMALIZE for such a specific > >> functionality seems a bit wrong. > > > > Would ALIGN RANGES/RANGE

Re: [HACKERS] Should we cacheline align PGXACT?

On Wed, Feb 15, 2017 at 2:15 PM, Andres Freund wrote: > I don't think that's true for several reasons. Separating out PGXACT > didn't just mean reducing the stride size of the access / preventing > sharing. It also meant that frequently changing fields in PGPROC aren't > on

Re: [HACKERS] Does having a NULL column automatically exclude the table from the tupleDesc cache?

> attcacheoff can only be set positive for fields preceding any varlena > (typlen<0, but including the first such) or nullable values. I don't > know how much faster it is with the cache; you can measure it if your > curiosity is strong enough -- just set the first column to nullable. > > Thanks!

[HACKERS] [PATCH] Teach Catalog.pm how many attributes there should be per DATA() line

Throws a build error if we encounter a different number of fields in a DATA() line than we expect for the catalog in question. Previously, it was possible to silently ignore any mismatches at build time which could result in symbol undefined errors at link time. Now we stop and identify the

Re: [HACKERS] bytea_output vs make installcheck

On Tue, Feb 14, 2017 at 9:17 PM, Andres Freund wrote: > > > On February 14, 2017 9:02:14 PM PST, neha khatri > wrote: > >On Wed, Feb 15, 2017 at 10:04 AM, neha khatri > > wrote:. > >> > >> > >>> Attached are two options for

Re: [HACKERS] Sum aggregate calculation for single precsion real

Robert Haas writes: > I think that's more or less the argument Konstantin is in fact making. > Whether it's a good argument or a thin one is a value judgement. > Personally, I find it somewhere in the middle: I think the way it > works now is reasonable, and I think what he

Re: [HACKERS] Should we cacheline align PGXACT?

On Wed, Feb 15, 2017 at 12:48 PM, Tom Lane wrote: > Robert Haas writes: >> ... Maybe that difference matters to the memory prefetching >> controller, I dunno, but it seems funny that we did the PGXACT work to >> reduce the number of cache lines that had

Re: [HACKERS] Should we cacheline align PGXACT?

Alexander Korotkov wrote: > Difference between master, pgxact-align-2 and pgxact-align-3 doesn't exceed > per run variation. FWIW this would be more visible if you added error bars to each data point. Should be simple enough in gnuplot ... -- Álvaro Herrera

Re: [HACKERS] Help text for pg_basebackup -R

Magnus Hagander wrote: > printf(_(" -R, --write-recovery-conf\n" > - " write recovery.conf after > backup\n")); > + " write recovery.conf for > replication\n")); > printf(_(" -S,

Re: [HACKERS] Should we cacheline align PGXACT?

Robert Haas writes: > ... Maybe that difference matters to the memory prefetching > controller, I dunno, but it seems funny that we did the PGXACT work to > reduce the number of cache lines that had to be touched in order to > take a snapshot to improve performance, and now

Re: [HACKERS] IF NOT EXISTS option for CREATE SERVER and CREATE USER MAPPING statements

13.02.2017 19:34, Andrew Dunstan: On 01/13/2017 08:36 AM, Anastasia Lubennikova wrote: I implemented IF NOT EXISTS option for CREATE SERVER and CREATE USER MAPPING statements for one of our customers. I think other users can also find it useful for scripting and automated tasks. The patches

Re: [HACKERS] Reporting xmin from VACUUMs

Jim Nasby wrote: > ISTR previous discussion of allowing more stats files; if that happened > I think having stats that were dedicated to (auto)vacuum would be very > useful. That's clearly a lot more work though. What? -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Does having a NULL column automatically exclude the table from the tupleDesc cache?

Ryan Murphy wrote: > My question kind of remains though - does that mean that having any nulls > in the tuple loses the ability to use the tupleDesc cache? and how much of > a performance impact is this? I'm sure there's a good reason why you can't > really use the cache if you have a null

Re: [HACKERS] Parallel Index Scans

On Wed, Feb 15, 2017 at 7:11 AM, Amit Kapila wrote:> > support related patch. In anycase, to avoid confusion I am attaching > all the three patches with this e-mail. Committed guc_parallel_index_scan_v1.patch, with changes to the documentation and GUC descriptions. --

Re: [HACKERS] renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.

On Tue, Feb 14, 2017 at 5:13 PM, Michael Paquier wrote: > On Wed, Feb 15, 2017 at 3:55 AM, Jeff Janes wrote: >> I thought people would object to checking the version number in two >> different places to make the same fundamental decision, and

Re: [HACKERS] error handling in RegisterBackgroundWorker

On Wed, Feb 15, 2017 at 11:30 AM, Peter Eisentraut wrote: > If RegisterBackgroundWorker() (the non-dynamic kind that is only > loadable from shared_preload_libraries) fails to register the worker, it > writes a log message and proceeds, ignoring the registration

Re: [HACKERS] Should we cacheline align PGXACT?

On Wed, Feb 15, 2017 at 12:14 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Feb 13, 2017 at 11:07 AM, Alvaro Herrera >> wrote: >>> It seems to me that Andres comments here were largely ignored: >>>

Re: [HACKERS] Does having a NULL column automatically exclude the table from the tupleDesc cache?

> No, that tests whether the particular tuple contains any null fields, not > whether the whole table is declared NOT NULL. > > regards, tom lane > Ok, thanks, that makes sense. My question kind of remains though - does that mean that having any nulls in the tuple loses

Re: [HACKERS] Documentation improvements for partitioning

On Wed, Feb 15, 2017 at 9:37 AM, Alvaro Herrera wrote: > Joshua D. Drake wrote: >> On 02/15/2017 06:10 AM, Simon Riggs wrote: >> > On 13 February 2017 at 05:21, Amit Langote >> > wrote: >> >> > If I issue DROP TABLE elsewhere, it doesn't

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Mon, Feb 13, 2017 at 8:52 PM, Amit Kapila wrote: > As discussed, attached are refactoring patches and a patch to enable > WAL for the hash index on top of them. 0006-Enable-WAL-for-Hash-Indexes.patch needs to be rebased after commit 8da9a226369e9ceec7cef1. --

[HACKERS] [PATCH] Fix pg_proc comment grammar

Fixes some DESCR() grammar mistakes introduced by the xlog -> wal changes. --- src/include/catalog/pg_proc.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/include/catalog/pg_proc.h b/src/include/catalog/pg_proc.h index 41c12af..bb7053a 100644 ---

Re: [HACKERS] Partitioned tables and relfilenode

On Wed, Feb 15, 2017 at 2:14 AM, Michael Paquier wrote: > This is a collection of checks on relkind == RELKIND_PARTITIONED_TABLE > to avoid interactions with partition tables. Did you consider doing > something in the executor instead? That seems inferior, because the

Re: [HACKERS] Documentation improvements for partitioning

On Wed, Feb 15, 2017 at 9:10 AM, Simon Riggs wrote: >>> * "ERROR: cannot create index on partitioned table >>> "measurement_year_month"" >>> is misleading because you can create indexes on partitions >> >> Do you mean that this should not cause an error at all, but create

Re: [HACKERS] [Bug fix] PQsendQuery occurs error when target_session_attrs is set to read-write

On Wed, Feb 15, 2017 at 1:31 AM, Michael Paquier wrote: > On Wed, Feb 15, 2017 at 11:08 AM, Robert Haas wrote: >> I think the patch as presented probably isn't quite what we want, >> because it waits synchronously for the second result to be

Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together

On 1/11/17 5:51 PM, David Rowley wrote: > Now, since background workers > don't consume anything from max_connections, then I don't really feel > that a background worker should count towards "CONNECTION LIMIT". I'd > assume any CONNECTION LIMITs that are set for a user would be > calculated based

Re: [HACKERS] Documentation improvements for partitioning

On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera wrote: > I think new-style partitioning is supposed to consider each partition as > an implementation detail of the table; the fact that you can manipulate > partitions separately does not really mean that they are their

Re: [HACKERS] Does having a NULL column automatically exclude the table from the tupleDesc cache?

Ryan Murphy writes: > My question is this: HeapTupleNoNulls() is run first to see if there are > any columns that can be NULL. It looks like the fetchatt() that uses the > cache in the tupleDesc can only be used if there are no NULLable columns in > the table. Is my

Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

On Tue, Feb 14, 2017 at 1:38 PM, Jim Nasby wrote: > On 2/14/17 3:13 AM, Seki, Eiji wrote: >> +extern TransactionId GetOldestXmin(Relation rel, uint8 ignoreFlags); > > > My impression is that most other places that do this sort of thing just call > the argument 'flags',

Re: [HACKERS] Should we cacheline align PGXACT?

On Mon, Feb 13, 2017 at 11:07 AM, Alvaro Herrera wrote: > It seems to me that Andres comments here were largely ignored: > https://www.postgresql.org/message-id/20160822021747.u5bqx2xwwjzac...@alap3.anarazel.de > He was suggesting to increase the struct size to 16 bytes

[HACKERS] Help text for pg_basebackup -R

The current help text for pg_basebackup -R is "write recovery.conf after backup". This says nothing about what it actually does. I've had a number of people ask me now why that's not default "because you need a recovery.conf to restore from backup". The point being that it doesn't say anything

  1   2   >