Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Wed, Aug 10, 2016 at 10:04 AM, Dilip Kumar wrote: > This seems better, after checking at other places I found that for > invalid type we are using ERRCODE_UNDEFINED_OBJECT and for invalid > functions we are using ERRCODE_UNDEFINED_FUNCTION. So I have done the > same way.

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

Hi 2016-08-03 13:54 GMT+02:00 Alexey Grishchenko : > On Wed, Aug 3, 2016 at 12:49 PM, Alexey Grishchenko < > agrishche...@pivotal.io> wrote: > >> Hi >> >> Current implementation of PL/Python does not allow the use of >> multi-dimensional arrays, for both input and output

Re: [HACKERS] Small issues in syncrep.c

On Tue, Aug 9, 2016 at 5:34 PM, Julien Rouhaud wrote: > Since 14e8803f1, it's not necessary to acquire the SyncRepLock to see up > to date data. But it looks like this commit didn't update all the > comment around MyProc->syncRepState, which still mention retrieving the

Re: [HACKERS] Wait events monitoring future development

From: pgsql-hackers-ow...@postgresql.org > Lets put this in perspective: there's tons of companies that spend thousands > of dollars per month extra by running un-tuned systems in cloud environments. > I almost called that "waste" but in reality it should be a simple business > question: is it

Re: [HACKERS] multivariate statistics (v19)

On Wed, Aug 3, 2016 at 10:58 AM, Tomas Vondra wrote: > 1) enriching the query tree with multivariate statistics info > > Right now all the stuff related to multivariate statistics estimation > happens in clausesel.c - matching condition to statistics, selection of >

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Tue, Aug 9, 2016 at 6:49 PM, Amit Kapila wrote: > Okay, then how about ERRCODE_UNDEFINED_OBJECT? It seems to be used in > almost similar cases. This seems better, after checking at other places I found that for invalid type we are using ERRCODE_UNDEFINED_OBJECT and

Re: [HACKERS] dsm_unpin_segment

On Wed, Aug 10, 2016 at 2:43 PM, Jim Nasby wrote: > On 8/9/16 6:14 PM, Thomas Munro wrote: >> The can't be static, they need to be in shared memory, because we also >> want to protect against two *different* backends pinning it. > > Right, this would strictly protect

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Tue, Aug 9, 2016 at 12:06 AM, Claudio Freire wrote: > On Mon, Aug 8, 2016 at 2:52 PM, Pavan Deolasee > wrote: > > > Some heuristics and limits on amount of work done to detect duplicate > index > > entries will help too. > > I think I prefer

Re: [HACKERS] dsm_unpin_segment

On 8/9/16 6:14 PM, Thomas Munro wrote: Could a couple of static variables be used to ensure multiple pin/unpin and > attach/detach calls throw an assert() (or become a no-op if asserts are > disabled)? It would be nice if we could protect users from this. The can't be static, they need to be in

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 8/9/16 6:44 PM, Claudio Freire wrote: Since we can lookup all occurrences of k1=a index=0 and k2=a index=0, and in fact we probably did so already as part of the update logic That's a change from what currently happens, right? The reason I think that's important is that dropping the

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 8/9/16 6:46 PM, Claudio Freire wrote: On Tue, Aug 9, 2016 at 8:44 PM, Claudio Freire wrote: index 0 1 2 3 4 k1 .. a a a k2 .. b a a i1 ^ i2 ^ ^ lp u u r3 hot* Sorry, that

Re: [HACKERS] handling unconvertible error messages

Hello, (I've recovered the lost Cc recipients so far) At Mon, 8 Aug 2016 12:52:11 +0300, Victor Wagner wrote in <20160808125211.1361c...@fafnir.local.vm> > On Mon, 08 Aug 2016 18:28:57 +0900 (Tokyo Standard Time) > Kyotaro HORIGUCHI wrote:

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Tue, Aug 9, 2016 at 06:19:57PM -0500, Jim Nasby wrote: > On 8/8/16 3:19 PM, Bruce Momjian wrote: > >>What will help, and something I haven't yet applied any thoughts, is when we > >>> can turn WARM chains back to HOT by removing stale index entries. > >I can't see how we can ever do that

Re: [HACKERS] Notice lock waits

On 8/5/16 12:00 PM, Jeff Janes wrote: So I created a new guc, notice_lock_waits, which acts like log_lock_waits but sends the message as NOTICE so it will show up on interactive connections like psql. I would strongly prefer that this accept a log level instead of being hard-coded to NOTICE.

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Tue, Aug 9, 2016 at 8:44 PM, Claudio Freire wrote: > index 0 1 2 3 4 > k1 .. a a a > k2 .. b a a > i1 ^ > i2 ^ ^ > lp u u r3 > hot* Sorry, that should read: index 0 1 2 3

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Tue, Aug 9, 2016 at 8:19 PM, Jim Nasby wrote: > On 8/8/16 3:19 PM, Bruce Momjian wrote: >>> >>> What will help, and something I haven't yet applied any thoughts, is when >>> we >>> > can turn WARM chains back to HOT by removing stale index entries. >> >> I can't see

Re: [HACKERS] Wait events monitoring future development

On 8/8/16 11:07 PM, Tsunakawa, Takayuki wrote: From: pgsql-hackers-ow...@postgresql.org > If you want to know why people are against enabling this monitoring by > default, above is the reason. What percentage of people do you think would > be willing to take a 10% performance penalty for

Re: [HACKERS] dsm_unpin_segment

On Wed, Aug 10, 2016 at 10:38 AM, Jim Nasby wrote: > On 8/9/16 1:01 PM, Robert Haas wrote: >> >> However, I don't see the need for a full-blown request >> counter here; we've had this API for several releases now and to my >> knowledge nobody has complained about the

Re: [HACKERS] Heap WARM Tuples - Design Draft

On 8/8/16 3:19 PM, Bruce Momjian wrote: What will help, and something I haven't yet applied any thoughts, is when we > can turn WARM chains back to HOT by removing stale index entries. I can't see how we can ever do that because we have multiple indexes pointing to the chain, and keys that

Re: [HACKERS] dsm_unpin_segment

On 8/9/16 1:01 PM, Robert Haas wrote: However, I don't see the need for a full-blown request counter here; we've had this API for several releases now and to my knowledge nobody has complained about the fact that you aren't supposed to call dsm_pin_segment() multiple times for the same segment.

Re: [HACKERS] Slowness of extended protocol

Robert Haas: > but for some reason you can't use prepared statements, for example because > the queries are dynamically generated and . That case is analogous to -M > extended, not -M prepared. And -M extended is well-known to be SLOWER > I do not buy that "dynamically generated queries defeat

Re: [HACKERS] per-statement-level INSTEAD OF triggers

Robert Haas writes: > On Mon, Aug 8, 2016 at 4:40 AM, Yugo Nagata wrote: >> I'm asking out of curiosity, do anyone know why we don't have >> per-statement-level INSTEAD OF triggers? I looked into the >> standard SQL (20xx draft), but I can't find the

Re: [HACKERS] per-statement-level INSTEAD OF triggers

On Mon, Aug 8, 2016 at 4:40 AM, Yugo Nagata wrote: > I'm asking out of curiosity, do anyone know why we don't have > per-statement-level INSTEAD OF triggers? I looked into the > standard SQL (20xx draft), but I can't find the restriction > such that INSTEAD OF triggers must

Re: [HACKERS] Logical Replication WIP

Petr Jelinek wrote: > On 09/08/16 10:13, Craig Ringer wrote: > >The only argument I can see for not using bgworkers is for the > >supervisor worker. It's a singleton that launches the per-database > >workers, and arguably is a job that the postmaster could do better. The > >current design there

Re: [HACKERS] Logical Replication WIP

Petr Jelinek wrote: > On 09/08/16 12:16, Craig Ringer wrote: > >Right. I think that's probably the direction we should be going > >eventually. Personally I don't think such a change should block the > >logical replication work from proceeding with bgworkers, though. > > Yeah that's why I added

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On Mon, Aug 8, 2016 at 12:22 AM, Etsuro Fujita wrote: >>> I noticed that currently the core doesn't show any information on the >>> target >>> relations involved in a foreign/custom join in EXPLAIN, by itself. >> I think that's a feature, not a bug. > I agree with

Re: [HACKERS] Slowness of extended protocol

On Tue, Aug 9, 2016 at 4:50 AM, Vladimir Sitnikov wrote: > I've tried pgbench -M prepared, and it is way faster than pgbench -M simple. That's true, but it's also testing something completely different from what Shay is concerned about. -M prepared creates a

[HACKERS] phrase search TS_phrase_execute code readability patch

Hackers, The attached attempts to make comprehension of the code in "TS_phrase_execute" a bit easier. I posted similar on the "typo patch" thread of July 2nd/5th but my comments there reflected my mis-understanding of the distance operator being exact as opposed to the expected

Re: [HACKERS] Slowness of extended protocol

On Tue, Aug 9, 2016 at 3:42 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Shay>But here's the more important general point. We're driver > developers, not application developers. I don't really know what > performance is "just fine" for each of my users, and what is not worth >

Re: [HACKERS] 9.6 phrase search distance specification

On Tue, Aug 9, 2016 at 12:59 PM, Ryan Pedela wrote: > > > Thanks, > > Ryan Pedela > Datalanche CEO, founder > www.datalanche.com > > On Tue, Aug 9, 2016 at 11:58 AM, Tom Lane wrote: > >> Bruce Momjian writes: >> > Does anyone know

Re: [HACKERS] 9.6 phrase search distance specification

Thanks, Ryan Pedela Datalanche CEO, founder www.datalanche.com On Tue, Aug 9, 2016 at 11:58 AM, Tom Lane wrote: > Bruce Momjian writes: > > Does anyone know why the phrase distance "<3>" was changed from "at most > > three tokens away" to "exactly three

Re: [HACKERS] 9.6 phrase search distance specification

On Tue, Aug 9, 2016 at 01:58:25PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Does anyone know why the phrase distance "<3>" was changed from "at most > > three tokens away" to "exactly three tokens away"? > > So that it would correctly support phraseto_tsquery's use of

Re: [HACKERS] dsm_unpin_segment

On Mon, Aug 8, 2016 at 8:53 PM, Tom Lane wrote: > Thomas Munro writes: >> Yeah, I was considering unbalanced pin/unpin requests to be a >> programming error. To be more defensive about that, how about I add a >> boolean 'pinned' to

Re: [HACKERS] 9.6 phrase search distance specification

Bruce Momjian writes: > Does anyone know why the phrase distance "<3>" was changed from "at most > three tokens away" to "exactly three tokens away"? So that it would correctly support phraseto_tsquery's use of the operator to represent omitted words (stopwords) in a phrase. I

Re: [HACKERS] patch: xmltable - proof concept

2016-08-09 19:30 GMT+02:00 Alvaro Herrera : > Pavel Stehule wrote: > > > postgres=# SELECT xmltable.* > > postgres-#FROM (SELECT data FROM xmldata) x, > > postgres-# LATERAL xmltable('/ROWS/ROW' > > postgres(# PASSING data > >

[HACKERS] 9.6 phrase search distance specification

Does anyone know why the phrase distance "<3>" was changed from "at most three tokens away" to "exactly three tokens away"? I looked at the thread at: https://www.postgresql.org/message-id/flat/33828354.WrrSMviC7Y%40abook and didn't see the answer. I assume if you are looking for "<3>"

Re: [HACKERS] patch: xmltable - proof concept

Pavel Stehule wrote: > postgres=# SELECT xmltable.* > postgres-#FROM (SELECT data FROM xmldata) x, > postgres-# LATERAL xmltable('/ROWS/ROW' > postgres(# PASSING data > postgres(# COLUMNS id int PATH '@id', > postgres(#

Re: [HACKERS] patch: xmltable - proof concept

Hi 2016-08-07 11:15 GMT+02:00 Pavel Stehule : > Hi > > I am sending a initial implementation of xmltable function: > > The code is not clean now, but it does almost of expected work. The usage > is simple. It is fast - 16K entries in 400ms. > > I invite any help with

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

Here is new version of the patch, now it includes recommendations from Anastasia Lubennikova. I've investigated anamalous index size decrease. Most probable version appeared to be true. Cube extension, as some others, use Guttman's polynomial time split algorithm. It is known to generate

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

> "Alvaro" == Alvaro Herrera writes: >> One idea is utils/adt/misc.c. Or we could make a new file under >> utils/adt/ though I'm not very sure what to name it. amaccess.c? >> catutils.c? If there's only ever likely to be one or two functions >> of this ilk,

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Peter Eisentraut writes: > Here is a small patch that sets log_line_prefix and application name in > pg_regress and the TAP tests, to make analyzing the server log output > easier. How would this interact with the buildfarm's existing policies on setting

[HACKERS] Set log_line_prefix and application name in test drivers

Here is a small patch that sets log_line_prefix and application name in pg_regress and the TAP tests, to make analyzing the server log output easier. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

Tom Lane wrote: > Andrew Gierth writes: > > Where'd be a good place to put that function? ruleutils? catalog/index.c ? > > > (ruleutils is way too big already) > > Agreed. catalog/index.c is not a place that implements SQL-visible > functions, so I don't like that

Re: [HACKERS] Slowness of extended protocol

Shay>But here's the more important general point. We're driver developers, not application developers. I don't really know what performance is "just fine" for each of my users, and what is not worth optimizing further. Users may follow best practices, or they may not for various reasons. Of

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

Andrew Gierth writes: > Where'd be a good place to put that function? ruleutils? catalog/index.c ? > (ruleutils is way too big already) Agreed. catalog/index.c is not a place that implements SQL-visible functions, so I don't like that either. One idea is

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

> "Kevin" == Kevin Grittner writes: >>> Building on the has-property approach Andrew suggested, I wonder if >>> we need something like pg_index_column_has_property(indexoid, colno, >>> propertyname) with properties like "sortable", "desc", "nulls first". >> >> This

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Mon, Aug 8, 2016 at 6:00 PM, Dilip Kumar wrote: > On Mon, Aug 8, 2016 at 5:23 PM, Amit Kapila wrote: >> >> >> Did you consider to use ERRCODE_UNDEFINED_COLUMN with error messages >> like: "type %u does not exit" or "type id %u does not exit"?

Re: [HACKERS] Slowness of extended protocol

On Tue, Aug 9, 2016 at 8:50 AM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Shay>There are many scenarios where connections are very short-lived > (think about webapps where a pooled connection is allocated per-request and > reset in between) > > Why the connection is reset in

Re: [HACKERS] Wait events monitoring future development

On Tue, Aug 9, 2016 at 04:17:28AM +, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org > > I used to think of that this kind of features should be enabled by default, > > because when I was working at the previous company, I had only few features > > to understand what is

Re: [HACKERS] Logical Replication WIP

On 09/08/16 12:16, Craig Ringer wrote: On 9 August 2016 at 17:28, Masahiko Sawada > wrote: > Sure, you can go deeper down the rabbit hole here and say that we need to > add bgworker "categories" with reserved pools of worker slots

Re: [HACKERS] Logical Replication WIP

On 9 August 2016 at 17:28, Masahiko Sawada wrote: > > Sure, you can go deeper down the rabbit hole here and say that we need to > > add bgworker "categories" with reserved pools of worker slots for each > > category. But do we really need that? > > If we change these

Re: [HACKERS] Logical Replication WIP

On Tue, Aug 9, 2016 at 5:13 PM, Craig Ringer wrote: > On 9 August 2016 at 15:59, Masahiko Sawada wrote: > >> >> >> The logical replication launcher process and the apply process are >> implemented as a bgworker. Isn't better to have them as an

Re: [HACKERS] Logical Replication WIP

On 09/08/16 10:13, Craig Ringer wrote: On 9 August 2016 at 15:59, Masahiko Sawada > wrote: The logical replication launcher process and the apply process are implemented as a bgworker. Isn't better to have them as an auxiliary

Re: [HACKERS] Logical Replication WIP

On 09/08/16 09:59, Masahiko Sawada wrote: On 2016-08-05 17:00:13 +0200, Petr Jelinek wrote: as promised here is WIP version of logical replication patch. Thank you for working on this! Thanks for looking! I've applied these patches to current HEAD, but got the following error.

Re: [HACKERS] Slowness of extended protocol

Shay>There are many scenarios where connections are very short-lived (think about webapps where a pooled connection is allocated per-request and reset in between) Why the connection is reset in between in the first place? In pgjdbc we do not reset per-connection statement cache, thus we easily

[HACKERS] Small issues in syncrep.c

Hello, Since 14e8803f1, it's not necessary to acquire the SyncRepLock to see up to date data. But it looks like this commit didn't update all the comment around MyProc->syncRepState, which still mention retrieving the value without and without lock. Also, there's I think a now unneeded test to

Re: [HACKERS] Logical Replication WIP

On Tue, Aug 9, 2016 at 5:13 PM, Craig Ringer wrote: > On 9 August 2016 at 15:59, Masahiko Sawada wrote: >> The logical replication launcher process and the apply process are >> implemented as a bgworker. Isn't better to have them as an auxiliary >>

Re: [HACKERS] Logical Replication WIP

On 9 August 2016 at 15:59, Masahiko Sawada wrote: > > The logical replication launcher process and the apply process are > implemented as a bgworker. Isn't better to have them as an auxiliary > process like checkpointer, wal writer? > I don't think so. The checkpointer,

Re: [HACKERS] Slowness of extended protocol

On Mon, Aug 8, 2016 at 6:44 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > > The problem with "empty statement name" is statements with empty name can >> be reused (for instance, for batch insert executions), so the server side >> has to do a defensive copy (it cannot predict how

Re: [HACKERS] Logical Replication WIP

On Sat, Aug 6, 2016 at 2:04 AM, Simon Riggs wrote: > On 5 August 2016 at 16:22, Andres Freund wrote: >> On 2016-08-05 17:00:13 +0200, Petr Jelinek wrote: >>> as promised here is WIP version of logical replication patch. >> >> Yay! > > Yay2 > Thank you

Re: [HACKERS] Declarative partitioning

What strikes me odd about these patches is RelOptInfo has remained unmodified. For a base partitioned table, I would expect it to be marked as partitioned may be indicating the partitioning scheme. Instead of that, I see that the code directly deals with PartitionDesc, PartitionKey which are part