Re: [HACKERS] multivariate statistics v14

On Wed, Mar 9, 2016 at 9:21 AM, Tomas Vondra wrote: > Hi, > > On Wed, 2016-03-09 at 08:45 -0800, Jeff Janes wrote: >> On Wed, Mar 9, 2016 at 7:02 AM, Tomas Vondra >> wrote: >> > Hi, >> > >> > thanks for the feedback. Attached is v14 of

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

2016-03-11 14:49 GMT+01:00 Robert Haas : > On Thu, Feb 18, 2016 at 9:23 AM, Daniel Verite > wrote: > > Dean Rasheed wrote: > > > >> If I want to sort the rows coming out of a query, my first thought > >> is always going to be to add/adjust

Re: [HACKERS] building on windows using VC 2008

On Sun, Mar 13, 2016 at 2:07 AM, Dave Cramer wrote: > Getting lots of POSTGRESQL_TRACE_... undefined. > > Any hints ? Those are coming from probes.h, that gets automatically generated in a VC build by running psed. My guess is that you are using ActivePerl 5.22 that does

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining? - and backup / restore issue

>> On 3/10/16 3:29 PM, Regina Obe wrote: >> Take for example, I have tiger geocoder which relies on fuzzystrmatch. I >> have no idea where someone installs fuzzystrmatch so I can't schema qualify >> those calls. I use that dependent function to use to build an index on >> tables. > This is

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 7:11 PM, Mithun Cy wrote: > > > > On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila wrote: > >With force_parallel_mode=on, I could see many other failures as well. I think it is better to have test, which tests this

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

> > On Fri, 2016-03-11 at 17:24 +0100, Michael Paquier wrote: > > On Fri, Mar 11, 2016 at 5:19 PM, Anastasia Lubennikova wrote: > > > > > > BTW, if you know a good way to corrupt index (and do it > > > reproducible) I'd be > > > very glad to see it. > > You can use for example dd in non-truncate

Re: [HACKERS] MinGW versus _strtoui64() ?

Petr Jelinek writes: > On 13/03/16 04:24, Tom Lane wrote: >> So you're thinking "#ifdef _MSC_VER"? Or something else? > Sorry for brevity, yes, that should work, afaics mingw has strtoul so > the code should compile fine with that ifdef. Also just checked to make > sure,

Re: [HACKERS] MinGW versus _strtoui64() ?

On 13/03/16 04:24, Tom Lane wrote: Petr Jelinek writes: On 13/03/16 03:30, Tom Lane wrote: Per a comment from Petr Jelinek, I added this in commit 23a27b039d94ba35: #ifdef WIN32 return _strtoui64(str, endptr, base); #else ... Several of the Windows buildfarm members

Re: [HACKERS] MinGW versus _strtoui64() ?

Petr Jelinek writes: > On 13/03/16 03:30, Tom Lane wrote: >> Per a comment from Petr Jelinek, I added this in commit 23a27b039d94ba35: >> >> #ifdef WIN32 >> return _strtoui64(str, endptr, base); >> #else ... >> >> Several of the Windows buildfarm members are good with

Re: [HACKERS] MinGW versus _strtoui64() ?

On 13/03/16 03:30, Tom Lane wrote: Per a comment from Petr Jelinek, I added this in commit 23a27b039d94ba35: #ifdef WIN32 return _strtoui64(str, endptr, base); #else ... Several of the Windows buildfarm members are good with that, but narwhal is not: numutils.c: In function

Re: [HACKERS] WIP: Upper planner pathification

Andres Freund writes: > On 2016-03-12 12:22:01 -0500, Tom Lane wrote: >> I wonder whether that's pathification per se. > If you're interested enough, I've uploaded a dump of the schema relevant > table to http://anarazel.de/t/lineitem_95_96_plan.dump.gz I haven't dug into

[HACKERS] MinGW versus _strtoui64() ?

Per a comment from Petr Jelinek, I added this in commit 23a27b039d94ba35: #ifdef WIN32 return _strtoui64(str, endptr, base); #else ... Several of the Windows buildfarm members are good with that, but narwhal is not: numutils.c: In function `pg_strtouint64': numutils.c:406: warning: implicit

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Sun, Mar 13, 2016 at 12:40 AM, Tom Lane wrote: > In short: we've already been over this territory, at length, > and I am not excited by people trying to bikeshed it again > after the fact, especially when no new arguments are being > presented. Can we call the discussion

Re: [HACKERS] checkpointer continuous flushing - V18

On Thu, Mar 10, 2016 at 11:25 PM, Peter Geoghegan wrote: > On Thu, Mar 10, 2016 at 11:18 PM, Fabien COELHO wrote: >> I can only concur! >> >> The "Performance Tips" chapter (II.14) is more user/query oriented. The >> "Server Administration" bool (III) does

[HACKERS] building on windows using VC 2008

Getting lots of POSTGRESQL_TRACE_... undefined. Any hints ? Dave Cramer

Re: [HACKERS] WIP: Upper planner pathification

On 2016-03-12 12:22:01 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2016-03-10 23:38:14 -0500, Tom Lane wrote: > >> I'll do it ... just send me the list. > > > After exporting make_agg, make_limit, make_sort_from_sortclauses and > > making some trivial adjustments

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

On Sat, Mar 12, 2016 at 2:53 PM, Peter Geoghegan wrote: > I said "basically uncontroversial", not "uncontroversial". That is a > perfectly accurate characterization of the patch, and if you disagree > than I suggest you re-read the thread. In particular, note that Alvaro

Re: [HACKERS] [GENERAL] OS X 10.11.3, psql, bus error 10, 9.5.1

unfortunately, I have to admit to my disgrace, that I'm still no C programmer after all these decades of dabbling in writing code. I just used the flags because someone at some point told me that it was a good idea, turns out, it's not [always]. I shall rebuild 9.5.1 without the -fno-common

Re: [HACKERS] Refectoring of receivelog.c

On 03/11/2016 11:15 AM, Magnus Hagander wrote: ... Pushed with updated comments and a named stsruct. Pretty sure this memset call in pg_basebackup.c is incorrect, as it passes parameters in the wrong order: MemSet(, sizeof(stream), 0); It seems benign, because we're setting all

Re: [HACKERS] [GENERAL] OS X 10.11.3, psql, bus error 10, 9.5.1

I wrote: > That's confusing because it implies that -fno-common is the default, > which it evidently is not. But anyway, my diagnosis is that you're > breaking something about the linker's behavior with that switch. Oh! Looking closer, the core dump happens here: const printTextFormat

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

On Sat, Mar 12, 2016 at 2:43 PM, Michael Paquier wrote: > Only one version of this patch has been sent at the beginning of this > thread, and Heikki has clearly expressed his disagreement about at > least a portion of it at the beginning of this thread, so I find it >

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

On Sat, Mar 12, 2016 at 11:24 PM, Peter Geoghegan wrote: > On Fri, Mar 11, 2016 at 5:26 AM, Robert Haas wrote: >> This patch was reviewed during CF 2016-01 and has not been updated for >> CF 2016-03. I think we should mark it Returned with Feedback. > > I

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

On Fri, Mar 11, 2016 at 5:26 AM, Robert Haas wrote: > This patch was reviewed during CF 2016-01 and has not been updated for > CF 2016-03. I think we should mark it Returned with Feedback. I have a full plate at the moment, Robert, both as a reviewer and as a patch

Re: [HACKERS] pam auth - add rhost item

On Sun, Mar 13, 2016 at 8:07 AM, Grzegorz Sampolski wrote: > Hi. > Thank you for improve documentation and yes I'm fine with this chages. Thanks. changed the patch status as ready for committer. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

I wrote: > 2. As I was just complaining to -hackers, plpython plperl and pltcl > all now contain attempts to pass uint64 values (from SPI_processed) > into language-specific functions. We need to figure out whether > that will overflow and whether it's worth doing something about. I fixed this

Re: [HACKERS] pam auth - add rhost item

Hi. Thank you for improve documentation and yes I'm fine with this chages. Regards. Grzegorz. On 03/12/2016 01:17 PM, Haribabu Kommi wrote: > On Fri, Mar 11, 2016 at 12:11 AM, Grzegorz Sampolski wrote: >> Hi. >> In attchment new patch with updated documentation and with small

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Fri, Mar 11, 2016 at 6:33 PM, Tomas Vondra wrote: > Right, but isn't there a difference between the two functions in this > respect? Once you find corruption involving relationship between > multiple pages, then I agree it's complicated to do any reasoning about >

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

On Saturday, March 12, 2016, David G. Johnston wrote: > On Saturday, March 12, 2016, Tom Lane > wrote: > >> "David G. Johnston" writes: >> > Don't the semantics of a

[HACKERS] Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat

Hi, On 2016-03-12 11:56:24 -0500, Robert Haas wrote: > On Fri, Mar 11, 2016 at 10:15 PM, Andres Freund wrote: > > On 2016-01-28 19:09:01 +, Robert Haas wrote: > >> Only try to push down foreign joins if the user mapping OIDs match. > >> > >> Previously, the foreign join

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

On Saturday, March 12, 2016, Tom Lane wrote: > "David G. Johnston" > writes: > > Don't the semantics of a SEMI JOIN also state that the output columns > only > > come from the outer relation? i.e., the inner relation doesn't

Re: [HACKERS] pl/pgSQL, get diagnostics and big data

Petr Jelinek writes: > On 12/03/16 04:30, Tom Lane wrote: >> 1. I found two places (marked XXX in this patch) that are using strtoul() >> to parse a tuple count back out of a command tag. That won't do anymore. >> pg_stat_statements has a messy hack for the same problem

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

Robert Haas writes: > You could also argue that's a compatibility break, because people may > have logic that assumes that a wait is always a heavyweight lock wait. > If we keep the column but change the meaning, people who need to > update their scripts may fail to notice.

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 13:59, Amit Kapila написал(а): > > On Sat, Mar 12, 2016 at 3:10 AM, Andres Freund > wrote: > > > > > > > Similarly for the wait event stuff - checkpointer, wal writer, > > > background writer are in

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 2:45, Andres Freund написал(а): > > On 2016-03-12 02:24:33 +0300, Alexander Korotkov wrote: >> Idea of individual time measurement of every wait event met criticism >> because it might have high overhead [1]. > > Right. And that's actually one of the

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

Robert Haas writes: > The new join pushdown code in postgres_fdw does not grok SEMI and ANTI > joins because there is no straightforward way of reducing those back > to SQL. They can originate in multiple ways and not all of those can > be represented easily. I think it

Re: [HACKERS] WIP: Upper planner pathification

Andres Freund writes: > On 2016-03-10 23:38:14 -0500, Tom Lane wrote: >> I'll do it ... just send me the list. > After exporting make_agg, make_limit, make_sort_from_sortclauses and > making some trivial adjustments due to the pull_var_clause changes > change, Citus' tests

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On Sat, Mar 12, 2016 at 11:06 AM, Tom Lane wrote: > Michael Paquier writes: >> On Fri, Mar 11, 2016 at 9:35 PM, Tom Lane wrote: >>> IMO this is not committable as-is, and I don't think that it's something >>> that will become

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 6:31 PM, Jim Nasby wrote: > On 3/10/16 8:36 PM, Robert Haas wrote: >> 1. We make it true only for heavyweight lock waits, and false for >> other kinds of waits. That's pretty strange. >> 2. We make it true for all kinds of waits that we now know

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

On Fri, Mar 11, 2016 at 4:32 PM, Tom Lane wrote: > So I started re-reading this thread in preparation for looking at the > patch, and this bit in your initial message jumped out at me: > >> In all of our join algorithms in the executor, if the join type is SEMI, >> we skip to

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 3/10/16 7:48 AM, Robert Haas wrote: I think the problem is that you can't show the name of a non-global SQL object (such as a relation) unless the object is in the current database. Many of the views in the first group are database-local views, while things like pg_locks span all databases.

[HACKERS] Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat

On Fri, Mar 11, 2016 at 10:15 PM, Andres Freund wrote: > On 2016-01-28 19:09:01 +, Robert Haas wrote: >> Only try to push down foreign joins if the user mapping OIDs match. >> >> Previously, the foreign join pushdown infrastructure left the question >> of security entirely

Re: [HACKERS] Perl's newSViv() versus 64-bit ints?

=?UTF-8?Q?Salvador_Fandi=c3=b1o?= writes: > On 03/12/2016 04:47 PM, Tom Lane wrote: >> How much of a user-visible change would that be, if the "processed" >> field of a spi_exec_query() result started coming back as an NV not >> an IV? I'm not sure how much that would affect

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

David Rowley writes: > On 12 March 2016 at 11:43, Tom Lane wrote: >>> I wondered why, instead of inventing an extra semantics-modifying flag, >>> we couldn't just change the jointype to *be* JOIN_SEMI when we've >>> discovered that the inner side

Re: [HACKERS] Perl's newSViv() versus 64-bit ints?

On 03/12/2016 04:47 PM, Tom Lane wrote: =?UTF-8?Q?Salvador_Fandi=c3=b1o?= writes: Another possibility is to just use newSVnv(), but NVs are not able to represent all the uint64 range precisely (IIRC, they can represent integers up to 48bits?). [ looks... ] Oh, NV is a

Re: [HACKERS] [PATCH] Use MemoryContextAlloc() in the MemoryContextAllocZero() and MemoryContextAllocZeroAligned()

Alexander Kuleshov writes: > Attached patch simplifies the MemoryContextAllocZero() and > MemoryContextAllocZeroAligned(). What this does is to de-inline those functions, resulting in an extra level of function call per allocation. We had intentionally inlined them on

Re: [HACKERS] eXtensible Transaction Manager API (v2)

Michael Paquier writes: > On Fri, Mar 11, 2016 at 9:35 PM, Tom Lane wrote: >> IMO this is not committable as-is, and I don't think that it's something >> that will become committable during this 'fest. I think we'd be well >> advised to boot it to

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

"David G. Johnston" writes: > Don't the semantics of a SEMI JOIN also state that the output columns only > come from the outer relation? i.e., the inner relation doesn't contribute > either rows or columns to the final result? Or is that simply > an implementation

Re: [HACKERS] Perl's newSViv() versus 64-bit ints?

=?UTF-8?Q?Salvador_Fandi=c3=b1o?= writes: > Another possibility is to just use newSVnv(), but NVs are not > able to represent all the uint64 range precisely (IIRC, they can > represent integers up to 48bits?). [ looks... ] Oh, NV is a "double", which I think would be a

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Robert Haas wrote: > But worse than either of those things, there is no real > agreement on what the overall design of this feature > should be. The part in the design that raised concerns upthread is essentially how headers sorting is exposed to the user and implemented. As suggested

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

On Saturday, March 12, 2016, David Rowley wrote: > On 12 March 2016 at 11:43, Tom Lane > > wrote: > > I wrote: > >> I wondered why, instead of inventing an extra semantics-modifying flag, > >> we couldn't just change the jointype to

Re: [HACKERS] auto_explain sample rate

On 11/03/2016 17:55, Robert Haas wrote: > On Fri, Mar 11, 2016 at 11:33 AM, Tomas Vondra > wrote: >> A bit late, but I think we should rename the GUC variable to >> "sampling_rate" (instead of sample_ratio) as that's what pgbench uses >> for the same thing. That'd be

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

Sorry there was some issue with my mail settings same mail got set more than once. -- Thanks and Regards Mithun C Y EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila wrote: >With force_parallel_mode=on, I could see many other failures as well. I think it is better to have test, which tests this functionality with >force_parallel_mode=regress as per user manual. Setting this value to

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila wrote: >With force_parallel_mode=on, I could see many other failures as well. I think it is better to have test, which tests this functionality with >force_parallel_mode=regress as per user manual. Setting this value to

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 2:32 PM, Amit Kapila wrote: >With force_parallel_mode=on, I could see many other failures as well. I think it is better to have test, which tests this functionality with >force_parallel_mode=regress as per user manual. Setting this value to

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Fri, Mar 11, 2016 at 2:31 PM, Amit Langote wrote: > On 2016/03/11 13:16, Robert Haas wrote: >> On Thu, Mar 10, 2016 at 9:04 PM, Amit Langote >> wrote: >>> So, from what I understand here, we should not put total count of index >>>

Re: [HACKERS] pam auth - add rhost item

On Fri, Mar 11, 2016 at 12:11 AM, Grzegorz Sampolski wrote: > Hi. > In attchment new patch with updated documentation and with small change > to coding style as you suggested. Thanks for the update. Here I attached updated patch with additional documentation changes, If you

Re: [HACKERS] Saving SRF context

On 03/11/2016 09:19 PM, Salvador Fandiño wrote: Hi, I have implemented a SRF[*] that returns rows one by one (using ExprMultipleResult). But now I need to save somewhere some context information between calls pertaining to the same result set and I am unable to find a proper place for that. I

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 2:38 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > > On Sat, Mar 12, 2016 at 2:45 AM, Andres Freund wrote: >> >> >> I think I agree with Robert here. Providing hooks into very low level >> places tends to lead to problems in my

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 12:45 AM, Andres Freund wrote: > On 2016-03-12 02:24:33 +0300, Alexander Korotkov wrote: > > > > So, situation looks like dead-end. I have no idea how to convince Robert > > about any kind of advanced functionality of wait monitoring to > PostgreSQL.

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 3:10 AM, Andres Freund wrote: > > > > Similarly for the wait event stuff - checkpointer, wal writer, > > background writer are in many cases processes that very often are > > blocked on locks, IO and such. Thus restricting the facility to > > database

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

On 12 March 2016 at 11:43, Tom Lane wrote: > I wrote: >> I wondered why, instead of inventing an extra semantics-modifying flag, >> we couldn't just change the jointype to *be* JOIN_SEMI when we've >> discovered that the inner side is unique. > > BTW, to clarify: I'm not

Re: [HACKERS] Proposal: RETURNING primary_key()

On 12/03/16 23:27, Michael Paquier wrote: On Fri, Mar 11, 2016 at 5:28 AM, Craig Ringer wrote: On 11 March 2016 at 03:07, Igal @ Lucee.org wrote: I noticed that you usually don't put html in the emails here, but I think that it's appropriate here to

Re: [HACKERS] Proposal: RETURNING primary_key()

On Fri, Mar 11, 2016 at 5:28 AM, Craig Ringer wrote: > On 11 March 2016 at 03:07, Igal @ Lucee.org wrote: >> I noticed that you usually don't put html in the emails here, but I think >> that it's appropriate here to show the information in a clear way

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On Fri, Mar 11, 2016 at 9:35 PM, Tom Lane wrote: > IMO this is not committable as-is, and I don't think that it's something > that will become committable during this 'fest. I think we'd be well > advised to boot it to the 2016-09 CF and focus our efforts on other stuff >

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 2:45 AM, Andres Freund wrote: > On 2016-03-12 02:24:33 +0300, Alexander Korotkov wrote: > > Idea of individual time measurement of every wait event met criticism > > because it might have high overhead [1]. > > Right. And that's actually one of the

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 2:02 PM, Mithun Cy wrote: > > > > On Sat, Mar 12, 2016 at 12:28 PM, Amit Kapila wrote > >I don't see how this test will fail with force_parallel_mode=regress and max_parallel_degree > 0 even without the patch proposed

Re: [HACKERS] [PATCH] Use MemoryContextAlloc() in the MemoryContextAllocZero() and MemoryContextAllocZeroAligned()

On Sat, Mar 12, 2016 at 8:09 AM, Alexander Kuleshov wrote: > Hello all, > > Attached patch simplifies the MemoryContextAllocZero() and > MemoryContextAllocZeroAligned(). > The MemoryContextAllocZero() and MemoryContextAllocZeroAligned() > functions does almost the > same

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Sat, Mar 12, 2016 at 12:28 PM, Amit Kapila wrote >I don't see how this test will fail with force_parallel_mode=regress and max_parallel_degree > 0 even without the patch proposed to fix the issue in >hand. In short, I don't think this test would have caught the issue,