On 11/18/2014 03:24 AM, Peter Geoghegan wrote:
Attached patch removes obsolete debugging #define in
pg_config_manual.h (RTDEBUG).
This was last used in commit 2a8d3d, from 2005. Apparently RTDEBUG is
a contraction of "R-Tree Debug".
Removed, thanks.
- Heikki
--
Sent via pgsql-hackers mailin
On Mon, 2014-11-17 at 18:04 +0100, Andres Freund wrote:
> That's quite possibly one culprit for the slowdown. Right now one
> AllocSetContext struct fits precisely into three cachelines. After your
> change it doesn't anymore.
Thank you! I made the same mistake as Tomas: I saw that
MemoryContextDa
On Wed, Oct 22, 2014 at 12:50 AM, Brightwell, Adam
wrote:
> Though, I would think that the general desire would be to keep the patch
> relevant ONLY to the necessary changes. I would not qualify making those
> types of changes as relevant, IMHO. I do think this is potential for
> cleanup, howeve
On Tue, Nov 18, 2014 at 5:47 AM, Simon Riggs wrote:
> On 21 August 2014 09:17, Julien Rouhaud wrote:
>
>> Track number of WAL files ready to be archived in pg_stat_archiver
>
> Would it be OK to ask what the purpose of this TODO item is?
>
> pg_stat_archiver already has a column for last_archived
> On 18 November 2014 05:19, Simon Riggs wrote:
>
>
> On 14 November 2014 11:02, Kouhei Kaigai
> wrote:
>
> > I'd like to throw community folks a question.
> > Did someone have a discussion to the challenge of aggregate
> push-down across
> > relations join in the past?
2014-11-17 23:58 GMT+01:00 Simon Riggs :
> >> Great, looks good to me, marking as ready for committer.
>
> What is wrong with using IF ?
>
It significantly increase code' length .. and decrease readability when you
intensive use a pattern IF THEN RAISE END IF - when you check every
parameter, whe
On 17 November 2014 16:05, Simon Riggs Wrote:
> I confirm 5% improvement in both short and long index scans, on the least
> beneficial datatype. Looks likely to be a very positive win overall.
Thanks a lot for testing and confirmation.
> The language used in the comments is not clear enough. I
Mats Erik Andersson wrote
> Hello there,
>
> I observe that the help text of vacuumdb for --analyze,
> --analyze-only, and --analyze-in-stages could do with
> a little clarification in order to be self-documenting
> and thus improve the user experience of vacuumdb.
>
> The problem is that the sol
Attached patch removes obsolete debugging #define in
pg_config_manual.h (RTDEBUG).
This was last used in commit 2a8d3d, from 2005. Apparently RTDEBUG is
a contraction of "R-Tree Debug".
--
Peter Geoghegan
diff --git a/src/include/pg_config_manual.h b/src/include/pg_config_manual.h
index 9e25ce0.
On 11/17/14, 4:58 PM, Simon Riggs wrote:
Great, looks good to me, marking as ready for committer.
What is wrong with using IF ?
It's a hell of a lot wordier. I've previously created a more sophisticated
"assert" framework to allow more control over things, but ended up also using
it just fo
On Tue, Nov 18, 2014 at 3:03 AM, Fujii Masao wrote:
> On Mon, Nov 17, 2014 at 2:20 PM, Michael Paquier
> wrote:
>> On Sun, Nov 16, 2014 at 9:07 PM, Michael Paquier
>> wrote:
>>> I'll send an updated patch tomorrow.
>>
>> Here are updated versions. I divided the patch into two for clarity,
>> the
On Tue, Nov 18, 2014 at 7:13 AM, Simon Riggs wrote:
> Committed.
>
> Thanks very much for pushing forwards with this.
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/17/2014 11:34 AM, Andres Freund wrote:
Hi,
Kevin: CCed you, because it doesn't really look like a logical decoding
related issue.
On 2014-11-17 11:25:40 -0500, Steve Singer wrote:
On 11/17/2014 10:37 AM, Andres Freund wrote:
On 2014-11-13 22:23:02 -0500, Steve Singer wrote:
Also since
Hello there,
I observe that the help text of vacuumdb for --analyze,
--analyze-only, and --analyze-in-stages could do with
a little clarification in order to be self-documenting
and thus improve the user experience of vacuumdb.
The problem is that the sole addition of the word "only" to
an otherw
Hello.
I was trying to get postgres to return the "correct" number of rows
inserted for batch inserts to a partitioned table [using the triggers as
suggested here
http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html results in
it always returning 0 by default].
What I ideally wanted it
>> Great, looks good to me, marking as ready for committer.
What is wrong with using IF ?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On 28 October 2014 11:34, Michael Paquier wrote:
> On Tue, Oct 28, 2014 at 8:08 PM, Petr Jelinek wrote:
>> Hi,
>>
>> On 28/10/14 03:15, Michael Paquier wrote:
>>>
>>>
>>> Updated patch with those comments addressed is attached.
>>
>>
>> Great, I have no further comments so I consider this patch r
On 17 November 2014 21:09, Alvaro Herrera wrote:
> What happened to this patch? I'm going over something that could use
> the concept of "clean some stuff up when reading this page, but only if
> we're already writing" or similar.
>
> I see some cases were presented that had a performance decreas
One interesting option would be kicking in an extra more expensive
planning cycle after the Nth run of the query, in general a lot of
these planned queries run 1000s of times, if you add some extra cost
to run 100 it may not be prohibitive cost wise.
On Tue, Nov 18, 2014 at 8:27 AM, Tom Lane wrot
Robert Haas writes:
> On Thu, Nov 13, 2014 at 7:34 PM, Tom Lane wrote:
>> One thing that occurs to me is that if the generic plan estimate comes
>> out much cheaper than the custom one, maybe we should assume that the
>> generic's cost estimate is bogus. Right offhand I can't think of a reason
>
What happened to this patch? I'm going over something that could use
the concept of "clean some stuff up when reading this page, but only if
we're already writing" or similar.
I see some cases were presented that had a performance decrease. Did we
get any numbers for the increase in performance
On 21 August 2014 09:17, Julien Rouhaud wrote:
> Track number of WAL files ready to be archived in pg_stat_archiver
Would it be OK to ask what the purpose of this TODO item is?
pg_stat_archiver already has a column for last_archived_wal and
last_failed_wal, so you can already work out how many
On Mon, Nov 17, 2014 at 10:15 AM, Robert Haas wrote:
> I'm grumpy about the distanceName() function. That seems too generic.
> If we're going to keep this as it is, I suggest something like
> computeRTEColumnDistance(). But see below.
Fair point.
> On a related note, I'm also grumpy about this
On 17.11.2014 19:46, Andres Freund wrote:
> On 2014-11-17 19:42:25 +0100, Tomas Vondra wrote:
>> On 17.11.2014 18:04, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2014-11-16 23:31:51 -0800, Jeff Davis wrote:
*** a/src/include/nodes/memnodes.h
--- b/src/include/nodes/memnodes.h
***
On Thu, Nov 13, 2014 at 4:57 PM, Jeff Davis wrote:
> On Thu, Nov 13, 2014 at 11:26 AM, Robert Haas wrote:
>> On Thu, Nov 13, 2014 at 3:38 AM, Jeff Davis wrote:
>> > If two backends both have an exclusive lock on the relation for a join
>> > operation, that implies that they need to do their own
On Thu, Nov 13, 2014 at 7:34 PM, Tom Lane wrote:
> One thing that occurs to me is that if the generic plan estimate comes
> out much cheaper than the custom one, maybe we should assume that the
> generic's cost estimate is bogus. Right offhand I can't think of a reason
> for a custom plan to look
On 18 November 2014 05:19, Simon Riggs wrote:
> On 14 November 2014 11:02, Kouhei Kaigai wrote:
>
> > I'd like to throw community folks a question.
> > Did someone have a discussion to the challenge of aggregate push-down
> across
> > relations join in the past? It potentially reduces number of
On 2014-11-17 19:42:25 +0100, Tomas Vondra wrote:
> On 17.11.2014 18:04, Andres Freund wrote:
> > Hi,
> >
> > On 2014-11-16 23:31:51 -0800, Jeff Davis wrote:
> >> *** a/src/include/nodes/memnodes.h
> >> --- b/src/include/nodes/memnodes.h
> >> ***
> >> *** 60,65 typedef struct Memo
On 17.11.2014 18:04, Andres Freund wrote:
> Hi,
>
> On 2014-11-16 23:31:51 -0800, Jeff Davis wrote:
>> *** a/src/include/nodes/memnodes.h
>> --- b/src/include/nodes/memnodes.h
>> ***
>> *** 60,65 typedef struct MemoryContextData
>> --- 60,66
>> MemoryContext nextchild;
On Sun, Nov 16, 2014 at 5:51 AM, Simon Riggs wrote:
> On 16 November 2014 06:59, Michael Paquier wrote:
>> 1) This patch is authorizing VACUUM and CLUSTER to use the event
>> triggers ddl_command_start and ddl_command_end, but aren't those
>> commands actually not DDLs but control commands?
>
> I
On Sat, Nov 15, 2014 at 7:36 PM, Peter Geoghegan wrote:
> Attached patch incorporates this feedback.
>
> The only user-visible difference between this revision and the
> previous revision is that it's quite possible for two suggestion to
> originate from the same RTE (there is exactly one change i
On Mon, Nov 17, 2014 at 2:20 PM, Michael Paquier
wrote:
> On Sun, Nov 16, 2014 at 9:07 PM, Michael Paquier
> wrote:
>> I'll send an updated patch tomorrow.
>
> Here are updated versions. I divided the patch into two for clarity,
> the first one is the actual refactoring patch, renaming
> SyncRepG
On Thu, Nov 13, 2014 at 12:38 PM, Fujii Masao wrote:
> Thanks for reviewing the patch!
>
> On Thu, Nov 13, 2014 at 4:05 AM, Alvaro Herrera
> wrote:
>> Fujii Masao wrote:
>>
>>> --- 127,152
>>>When this option is used, pg_receivexlog will
>>> report
>>>a flush positio
On Sat, Nov 15, 2014 at 5:51 PM, David Rowley wrote:
> With pgbench I can do:
>
> \setrandom qty 24 25
> then throw a :qty into the query and have pgbench replace that with either
> 24 or 25.
>
> The problem is that this does not work for anything apart from integer
> types.
I've got a pending pa
Christoph Berg writes:
> Re: Tom Lane 2014-11-17 <6903.1416241...@sss.pgh.pa.us>
>> The point is to find out how many people care ...
> Is the point of this to figure out whether to fix this properly, or to
> revert to the old code? The current status isn't something that should
> be released wit
On 17.11.2014 08:31, Jeff Davis wrote:
> On Sat, 2014-11-15 at 21:36 +, Simon Riggs wrote:
>> Do I understand correctly that we are trying to account for exact
>> memory usage at palloc/pfree time? Why??
>
> Not palloc chunks, only tracking at the level of allocated blocks
> (that we allocate
On Mon, Nov 10, 2014 at 3:33 PM, Peter Geoghegan wrote:
> * Documentation clean-up - as I mentioned, I tried to address Simon's
> concerns here. Also, as you'd expect, the documentation has been fixed
> up to reflect the new syntax. I'll need to take a pass at updating the
> UPSERT Wiki page soon,
Hi,
On 2014-11-16 23:31:51 -0800, Jeff Davis wrote:
> *** a/src/include/nodes/memnodes.h
> --- b/src/include/nodes/memnodes.h
> ***
> *** 60,65 typedef struct MemoryContextData
> --- 60,66
> MemoryContext nextchild;/* next child of same parent */
> char
On 15.11.2014 22:36, Simon Riggs wrote:
> On 16 October 2014 02:26, Jeff Davis wrote:
>
>> The inheritance is awkward anyway, though. If you create a tracked
>> context as a child of an already-tracked context, allocations in
>> the newer one won't count against the original. I don't see a way
Re: Tom Lane 2014-11-17 <6903.1416241...@sss.pgh.pa.us>
> Christoph Berg writes:
> > In HEAD, there's this WARNING now:
> > WARNING: type input function chkpass_in should not be volatile
>
> Yeah, that's intentional.
>
> > IMHO built-in functions (even if only in contrib) shouldn't be raising
>
Hi,
Kevin: CCed you, because it doesn't really look like a logical decoding
related issue.
On 2014-11-17 11:25:40 -0500, Steve Singer wrote:
> On 11/17/2014 10:37 AM, Andres Freund wrote:
> >On 2014-11-13 22:23:02 -0500, Steve Singer wrote:
> >
> >
> >Also since updating (to 2c267e47afa4f9a7c) I'
On 11/17/2014 10:37 AM, Andres Freund wrote:
On 2014-11-13 22:23:02 -0500, Steve Singer wrote:
Also since updating (to 2c267e47afa4f9a7c) I've seen a assertion failure in
a normal client connection, not the walsender
#3 0x006b4978 in GetSerializableTransactionSnapshotInt (
snapsh
Christoph Berg writes:
> In HEAD, there's this WARNING now:
> WARNING: type input function chkpass_in should not be volatile
Yeah, that's intentional.
> IMHO built-in functions (even if only in contrib) shouldn't be raising
> warnings - the user can't do anything about the warnings anyway, so
>
On 17 November 2014 16:01, Robert Haas wrote:
> I still don't know what CONTAINS NO SQL means.
It's a function marking that would indicate we aren't allowed to take
snapshots or run SQL.
I think you should publish the scheme for marking functions as safe
for parallelism, so we can judge that.
Re: Tom Lane 2014-11-05 <29132.1415144...@sss.pgh.pa.us>
> I wrote:
> > An alternative that just occurred to me is to put the no-volatile-
> > I/O-functions check into CREATE TYPE, but make it just WARNING not
> > ERROR. That would be nearly as good as an ERROR in terms of nudging
> > people who'd
On 14 November 2014 11:02, Kouhei Kaigai wrote:
> I'd like to throw community folks a question.
> Did someone have a discussion to the challenge of aggregate push-down across
> relations join in the past? It potentially reduces number of rows to be
> joined.
> If we already had, I'd like to chec
On 17 November 2014 07:31, Jeff Davis wrote:
> To calculate the total memory used, I included a function
> MemoryContextMemAllocated() that walks the memory context and its
> children recursively.
If we assume that we want the results accurate to within 5%, then we
can work out a good sampling r
This tiny change fixes what I think is a longstanding bug in psql. I
causes the first line of every cell to be counted twice, whereas it
should in fact be excluded from extra_lines / extra_row_output_lines.
The bug appears to date back to commit 43ee2282 in 2008. Changing it
appears to make m
On 17 November 2014 07:31, Jeff Davis wrote:
> On Sat, 2014-11-15 at 21:36 +, Simon Riggs wrote:
>> Do I understand correctly that we are trying to account for exact
>> memory usage at palloc/pfree time? Why??
>
> Not palloc chunks, only tracking at the level of allocated blocks (that
> we all
On Fri, Nov 14, 2014 at 11:47 AM, Andres Freund wrote:
> On 2014-11-13 11:41:18 -0500, Robert Haas wrote:
>> On Wed, Nov 12, 2014 at 7:31 PM, Andres Freund
>> wrote:
>> > But I think it won't work realistically. We have a *lot* of
>> > infrastructure that refers to indexes using it's primary key
On Thu, Nov 13, 2014 at 7:27 PM, Simon Riggs wrote:
> On 12 November 2014 00:54, Robert Haas wrote:
>> On Tue, Nov 11, 2014 at 3:29 AM, Simon Riggs wrote:
>>> * only functions marked as "CONTAINS NO SQL"
>>> We don't really know what proisparallel is, but we do know what
>>> CONTAINS NO SQL mean
On Thu, Nov 13, 2014 at 10:59 PM, Fujii Masao wrote:
> 442231d7f71764b8c628044e7ce2225f9aa43b6 introduced the latter rule
> for hot-standby case. Maybe *during crash recovery* (i.e., hot standby
> should not be enabled) it's better to treat the crash of startup process as
> a catastrophic crash.
The "special" area in a BRIN page looks like this:
/* special space on all BRIN pages stores a "type" identifier */
#define BRIN_PAGETYPE_META 0xF091
#define BRIN_PAGETYPE_REVMAP0xF092
#define BRIN_PAGETYPE_REGULAR 0xF093
...
typ
On 2014-11-13 22:23:02 -0500, Steve Singer wrote:
> On 11/13/2014 02:44 PM, Andres Freund wrote:
> >H
>
> >I've pushed a fix for a bug that could possibly also cause
> >this. Although it'd be odd that it always hits the user catalog
> >table. Except if your tests mostly modify the slony tables, bu
On 2014-11-17 10:33:52 -0500, Steve Singer wrote:
> On 11/16/2014 04:49 PM, Steve Singer wrote:
> >
> >
> >I installed things following the above steps on a different system than my
> >usual development laptop and I have been unable to reproduce the error so
> >for (on that system). But I am still
On 11/16/2014 04:49 PM, Steve Singer wrote:
I installed things following the above steps on a different system
than my usual development laptop and I have been unable to reproduce
the error so for (on that system). But I am still able to reproduce
it on occasion on my normal development lap
On Mon, Nov 17, 2014 at 10:31 AM, Andres Freund wrote:
> On 2014-11-17 10:21:04 -0500, Robert Haas wrote:
>> Andres, where are we with this patch?
>>
>> 1. You're going to commit it, but haven't gotten around to it yet.
>>
>> 2. You're going to modify it some more and repost, but haven't gotten
>>
On Thu, Nov 13, 2014 at 9:12 PM, Stephen Frost wrote:
>> > I'm not a fan of using pg_class- there are a number of columns in there
>> > which I would *not* wish to be allowed to be different per partition
>> > (starting with relowner and relacl...). Making those NULL would be just
>> > as bad (pr
On 2014-11-17 10:21:04 -0500, Robert Haas wrote:
> Andres, where are we with this patch?
>
> 1. You're going to commit it, but haven't gotten around to it yet.
>
> 2. You're going to modify it some more and repost, but haven't gotten
> around to it yet.
>
> 3. You're willing to see it modified i
Andres Freund writes:
>
> I've invested some more time in this:
> 0002 now makes sense on its own and doesn't change anything around the
> interrupt handling. Oh, and it compiles without 0003.
In this patch, the endif appears to be misplaced in PostgresMain:
+ if (MyProcPort != NULL)
On Sat, Oct 25, 2014 at 1:50 AM, Amit Kapila wrote:
> On Fri, Oct 24, 2014 at 4:05 PM, Andres Freund
> wrote:
>>
>> On 2014-10-24 15:59:30 +0530, Amit Kapila wrote:
>> > > > and w.r.t performance it can lead extra
>> > > > function call, few checks and I think in some cases even can
>> > > > acqu
On 2014-11-17 11:51:54 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > Hi,
> >
> > On 2014-10-25 18:09:36 -0400, Steve Singer wrote:
> > > I sometimes get the error "snapshot too large" from my logical replication
> > > walsender process when in response to a CREATE_REPLICATION_SLOT.
> >
Andres Freund wrote:
> Hi,
>
> On 2014-10-25 18:09:36 -0400, Steve Singer wrote:
> > I sometimes get the error "snapshot too large" from my logical replication
> > walsender process when in response to a CREATE_REPLICATION_SLOT.
>
> Yes. That's possible if 'too much' was going on until a consiste
On Thu, Nov 6, 2014 at 8:00 PM, Fujii Masao wrote:
> On Fri, Oct 24, 2014 at 3:41 AM, FabrÃzio de Royes Mello
> wrote:
>> On Wed, Oct 22, 2014 at 9:21 PM, Alvaro Herrera
>> wrote:
>>>
>>> Sawada Masahiko wrote:
>>>
>>> > Thank you for reviewing.
>>> > I agree 2) - 5).
>>> > Attached patch is lat
On 11/17/2014 03:22 PM, Heikki Linnakangas wrote:
Here is an updated version of the patch. It's rebased over current
master, and fixes a bunch of issues you and Michael pointed out, and a
ton of other cleanup.
That patch had two extra, unrelated patches applied to it. One to use
the Intel CRC
Alvaro Herrera wrote:
> I wrote an identical patch on Saturday and watched it pass
> CLOBBER_CACHE_ALWAYS test on Sunday. But the reason I didn't push is I
> couldn't understand *why* is there a problem here. I imagine that the
> source of the issue is supposed to be a relcache invalidation that
Michael Paquier wrote:
> The complaint comes from jaguarundi, like here:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2014-11-16%2015%3A33%3A23
>
> As Tom mentioned, adding a new parameter to set the persistence
> through RelationSetNewRelfilenode works. Patch, actually
Andres Freund writes:
> On 2014-11-15 00:11:36 +0300, Alex Shulgin wrote:
>> After reading up through archives on the two $subj related TODO items
>> I'm under impression that the patches[1,2] didn't make it mainly because
>> of the risk of breaking SSL internals if we try to longjump out of the
On Mon, Nov 17, 2014 at 10:00 PM, Simon Riggs wrote:
> On 16 November 2014 12:07, Michael Paquier wrote:
>
>> Let's work
>> the multiple node thing once we have a better spec of how to do it,
>> visibly using a dedicated micro-language within s_s_names.
>
> Hmm, please make sure that is a new pos
On 16 November 2014 12:07, Michael Paquier wrote:
> Let's work
> the multiple node thing once we have a better spec of how to do it,
> visibly using a dedicated micro-language within s_s_names.
Hmm, please make sure that is a new post. That is easily something I
could disagree with, even though
On 11/14/2014 10:31 AM, Michael Paquier wrote:
5) Here why not using the 2nd block instead of the 3rd (@_bt_getroot)?
+ XLogBeginInsert();
+ XLogRegisterBuffer(0, rootbuf, REGBUF_WILL_INIT);
+ XLogRegisterBuffer(2, metabuf, REGBUF_
Hi Fujita-san,
Here are comments for postgres_fdw-syscol patch.
Sanity
The patch applies and compiles cleanly.
The server regression and regression in contrib/postgres_fdw,file_fdw run
cleanly.
Code
---
1. Instead of a single liner comment "System columns can't be sent to
remote.",
Hi Fujita-san,
Here are my comments about the patch fscan_reltargetlist.patch
Sanity
Patch applies and compiles cleanly.
Regressions in test/regress folder and postgres_fdw and file_fdw are clean.
1. This isn't your change, but we might be able to get rid of assignment
2071 /* Are an
On 17 November 2014 05:49, Rajeev rastogi wrote:
>> * Single column bigint index
> It gives around 5% improvement.
I confirm 5% improvement in both short and long index scans, on the
least beneficial datatype. Looks likely to be a very positive win
overall.
TEST 1: 10x
select id2 in
Hi Fujita-san,
Here are my review comments for patch fdw-inh-3.patch.
Sanity
1. The patch applies cleanly
2. It compiles cleanly.
3. The server regression tests and tests in contrib modules pass.
Tests
---
1. It seems like you have copied from testcase inherit.sql to postgres_fdw
tes
On Mon, Nov 17, 2014 at 5:56 AM, Christian Ullrich wrote:
> * Alvaro Herrera wrote:
>
>> Michael Paquier wrote:
>>
>>> Btw, perhaps this diff should be pushed as a different patch as this is a
>>> rather different thing:
>>> - if (heapRelation->rd_rel->relpersistence ==
>>> RELPERSISTENCE_UN
76 matches
Mail list logo
