On Wed, 10 Aug 2016 11:08:43 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI wrote:
> 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
On Fri, Jun 3, 2016 at 8:51 PM, Dmitry Igrishin wrote:
>> BTW, I've publushed the HTML-ified SGML docs to
>> http://2ndquadrant.github.io/postgres/libpq-batch-mode.html as a preview.
> Typo detected: "Returns 1 if the batch curently being received" -- "curently".
I am looking a bit more seriously
On 10 August 2016 at 07:09, Jim Nasby wrote:
>
>
The downside to leaving stuff like this off by default is users won't
> remember it's there when they need it. At best, that means they spend more
> time debugging something than they need to. At worse, it means they suffer
> a production outage f
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.
>
> Updated patch attac
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 parameters. This forces
>
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
> value without and without
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 wort
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
> statistics to use (if there are
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 for invalid
functions we ar
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 from it happening within a sin
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 a more thorough approach.
>
> Increment/decrement m
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
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 assumpt
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 should read:
index 0 1
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:
> >
> > I don't see charset compatibility to be easil
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 becaus
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. T
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 4
k1 .. a
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 how we can ever do that beca
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 monito
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 fact that you aren't
>> suppos
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 might
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.
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
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 restriction
>> such that INSTEAD OF triggers m
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 be row-level. Is there
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 st
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 lo
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 you. I'd leave that for 10.0.
I
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 prepared
statement once, and then exe
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
less-than-or-equal
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
> opt
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 why the phrase distance "<3>" was changed from "at most
>> > thr
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 tokens away"?
>
> So that it would corre
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 the operator
> to
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 dsm_control_item, and elog(ERROR, ...) if it's not
>> in the exp
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 think there's prob
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
> > postgres(#
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>"
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(#
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 documentation and testing.
>
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 "needle-
> "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, maybe a new file is overkill
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 log_line_prefix?
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 0595672e92
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 either.
>
> One idea is utils
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 course
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 utils/adt/misc.c. Or we could make a n
> "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 seems simple enough,
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"? Errorcode
>> ERRCODE_UNDEFINED_COLUMN seems to be u
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 betwee
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 h
On 09/08/16 12:16, Craig Ringer wrote:
On 9 August 2016 at 17:28, Masahiko Sawada mailto:sawada.m...@gmail.com>> 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. Bu
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 processes to bgworker, we ca
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
>> process like checkpointer, wal writer?
>
On 09/08/16 10:13, Craig Ringer wrote:
On 9 August 2016 at 15:59, Masahiko Sawada mailto:sawada.m...@gmail.com>> 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,
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.
libpqwal
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
reu
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 tr
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
>> process like checkpointer, wal writer?
>
> I don
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, walwriter, autovacuum, e
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 man
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 for working on this!
I've applied these pat
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 o
64 matches
Mail list logo
