On Wednesday, 21 October 2015, Amit Kapila wrote:
> On Tue, Oct 20, 2015 at 8:16 PM, Robert Haas > wrote:
> >
> > On Sat, Oct 17, 2015 at 6:17 PM, Robert Haas > wrote:
> > > It's good to have your perspective on how this can be improved, and
> > > I'm definitely willing to write more documentat
On 2015/10/22 18:20, Fabien COELHO wrote:
>>
>>> progress: 365.0 s, 18392.1 tps, lat 94.857 ms stddev 23.917, lag 90.980
>>> ms, 106244 skipped
>>>
>>> 100k skipped transactions at a rate limit of 40k? That doesn't seem right.
>>
>> Argh. It's just because I used -P5. It's a bit confusing that the
On 2015/10/23 6:06, Robert Haas wrote:
> On Wed, Oct 21, 2015 at 1:51 AM, Amit Langote
> wrote:
>> Attached adds those.
>
> Good catch. Committed and back-patched to 9.5.
>
> (Yes, one of these problems goes back to 9.3, but it's a minor issue
> so I didn't
On 2015/10/23 18:51, Etsuro Fujita wrote:
> On 2015/10/23 6:06, Robert Haas wrote:
>> Good catch. Committed and back-patched to 9.5.
>
> Thanks, Amit and Robert!
>
> This is really really nitpicking, but I noticed that there is an implicit
> rule concerning the message format in ATWrongRelkindEr
On 2015/10/23 19:02, Amit Langote wrote:
> On 2015/10/23 18:51, Etsuro Fujita wrote:
>>
>> This is really really nitpicking, but I noticed that there is an implicit
>> rule concerning the message format in ATWrongRelkindError; if more than
>> two objects are present, th
On 2015/10/28 12:57, Muthiah Rajan wrote:
> Hello Kevin,
>
> This may be a trivial thing But what do you mean by shops? I actually
> can't get it :-)
I think it's casually used to mean a company or a production environment.
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-h
On 2015/10/29 17:10, Robert Haas wrote:
> On Thu, Oct 29, 2015 at 2:40 AM, Robins wrote:
>> Was reviewing recent commits, and it seems the following commit adds an
>> extra line to some comments. Just wanted to cross-check if that was
>> intentional.
>
> I don't see that it changed any comments a
Robins,
On 2015/10/29 10:40, Robins wrote:
> Hi,
>
> Was reviewing recent commits, and it seems the following commit adds an
> extra line to some comments. Just wanted to cross-check if that was
> intentional.
>
> Commit: http://goo.gl/zxA00l
> Pre-Commit: http://goo.gl/2DpLxi
> Post-Commit: ht
Horiguchi-san,
On 2015/11/05 18:10, Kyotaro HORIGUCHI wrote:
> Hello. I don't know whether this is a bug fix or improvement,
Would it be 50-50? :-)
...
>
> During the investigation into this issue, I found a mistake in
> the comment for PQmblen. It give the byte length of the character
> at t
On 2015/11/07 3:55, Robert Haas wrote:
> On Sun, Jun 28, 2015 at 10:43 PM, Amit Langote
> wrote:
>> On 2015-06-29 AM 11:36, Amit Langote wrote:
>>> Hi,
>>>
>>> How about the attached that adjusts errorcode for the error relate
On 2015/11/10 0:56, Robert Haas wrote:
> On Sat, Nov 7, 2015 at 12:07 PM, Corey Huinker
> wrote:
>> Sorry to barge in late, but I was wondering if what we've learned with this
>> patch can be applied to the case of asserting a sort order on a query
>> returning from dblink().
>
> Nope.
>
> Sorr
On 2015/10/29 23:22, Syed, Rahila wrote:
>
> Please find attached an updated patch.
>
Thanks for the v6. A few quick comments:
- duplicate_oids error in HEAD.
- a compiler warning:
pgstat.c:2898: warning: no previous prototype for ‘pgstat_reset_activityflag’
To fix that use void for empty pa
On 2015/10/29 23:22, Syed, Rahila wrote:
> Please find attached an updated patch.
A few more comments on v6:
> relname = RelationGetRelationName(onerel);
> + schemaname = get_namespace_name(RelationGetNamespace(onerel));
> ereport(elevel,
> (errmsg("vacuuming
On Wed, Nov 11, 2015 at 11:53 PM, Robert Haas wrote:
> For those following along at home, here's a demo:
>
> rhaas=# \timing
> Timing is on.
> rhaas=# select * from pgbench_accounts where filler like '%a%';
> aid | bid | abalance | filler
> -+-+--+
> (0 rows)
>
> Time: 743
On 2015/11/12 4:26, Robert Haas wrote:
> On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule
> wrote:
>> I have a first query
>>
>> I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are
>> differen
>
> Hmm, I see I was right about people finding more bugs once this was
> committed.
On 2015/11/12 14:09, Kouhei Kaigai wrote:
> I'm now designing the parallel feature of Append...
>
> Here is one challenge. How do we determine whether each sub-plan
> allows execution in the background worker context?
>
> The commit f0661c4e8c44c0ec7acd4ea7c82e85b265447398 added
> 'parallel_aware
On 2015/11/02 23:36, Craig Ringer wrote:
> On 2 November 2015 at 20:17, Craig Ringer wrote:
>> Hi all
>>
>> I'd like to submit pglogical_output for inclusion in the 9.6 series as
>> a contrib.
>
> Here's the protocol documentation discussed in the README. It's
> asciidoc at the moment, so it can
On Tue, Nov 10, 2015 at 5:02 PM, Amit Langote
wrote:
> On 2015/10/29 23:22, Syed, Rahila wrote:
> How about the following instead -
>
> + snprintf(progress_message[0], PROGRESS_MESSAGE_LENGTH, "%s",
> + generate_relation_name(oner
Langote
Date: Fri, May 17, 2013 at 1:29 AM
Subject: Re: [HACKERS] Logging of PAM Authentication Failure
To: Tom Lane
Cc: Andres Freund , Kyotaro HORIGUCHI
, Kyotaro HORIGUCHI
, Robert Haas
, PostgreSQL-development
On Fri, May 17, 2013 at 1:05 AM, Tom Lane wrote:
> Amit Langote writes:
&g
HeapTuple, there is a union that is named t_choice,
> union
> {
> HeapTupleFields t_heap;
> DatumTupleFields t_datum;
> }t_choice;
>
> I can't find out why we need t_datum, actually there is no comment about
> DatumTupleFields.
>
&g
gt; If a tuple constructed in memory we don't need t_heap. I have another
> question,
> How make an in-memory tuple?
>
>
>
>
> On Mon, May 20, 2013 at 12:46 PM, Amit Langote
> wrote:
>>
>> Hello,
>>
>> I think the comment just above the HeapTupleField
Wonder though if this question is better asked in pgsql-novice?
On Mon, May 20, 2013 at 9:23 PM, Amit Langote wrote:
> Hello,
>
> I think a more appropriate question to be asked here would be at what
> point (in the life of a typical tuple), does a tuple's header contain
>
w--- 1 postgres postgres 16777216 May 21 14:53 0001000E007D
-rw--- 1 postgres postgres 16777216 May 21 14:53 0001000E007E
-rw--- 1 postgres postgres 16777216 May 21 14:53 0001000E007F
-rw--- 1 postgres postgres 16777216 May 21 14:53 0001000E0080
Is t
n his pg_xlog as he reported in pgsql-admin thread) is
pre-allocated already?
I think we could ask the user the latest value of "select
pg_xlogfile_name(pg_xlog_current_location())".
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
bout similar (around 12:10), whereas the latest modified time (15:37)
is of segment 0001000E00A7.
Wonder if whatever configuration he is using is sub-optimal that these
many WAL segments can be re-cycled upon a checkpoint? Or is this okay?
--
Amit Langote
--
Sent via pgsql-hackers mai
an stall server be
limited to statement_timeout amount of time?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rtion of data, to make
> it faster. Then I switch to wal_level=hot_standby, i.e the "production"
> configuration, and the WAL segment seuqence seems to overlap with the
> segments generated with the other setting.
>
Though, now you understand it's not what it looks like,
imes in your "ls -l" listing.
0001000E00A7 has May 22 15:32 (the latest writes seem to
have happened to this segment) whereas pre-allocated ones seem to have
around May 22 12:05 to 12:15 (which are yet to be written to).
Does that help?
--
Amit Langote
--
Sent via pgsql-hac
checkpoint_timeout, wal_keep_segments?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ared memory?
>
An index is built in backend process's local memory, but, when
accessing, index pages are stored in shared memory. That is, for
example, when an index scan is performed, index pages are brought into
shared memory and accessed from there.
--
Amit Langote
--
Sent via pgsql-h
it.
>
> The other information being locks?
CreateSharedMemoryAndSemaphores() (src/backend/storage/ipc/ipci.c)
seems to be the place where we can see what all things reside in
shared memory, since at the beginning of the function, you can see
size being computed for shared memory to hold all the things that
to password
required), get password using a prompt and then create a new
connection with password included in the request.
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, May 28, 2013 at 5:04 PM, Amit Langote wrote:
> On Tue, May 28, 2013 at 2:32 PM, Craig Ringer wrote:
>> On 05/11/2013 03:25 AM, Robert Haas wrote:
>>> Not really. We could potentially fix it by extending the wire
>>> protocol to allow the server to respond to
gme19wdtw9tefw_w7h2ns4e+yysjkb9wd...@mail.gmail.com),
but things didn't change.
So, it appears, for search strings consisting of 2 (or < 3)
characters, trigrams can not be utilized. No?
NOTE: Using the master branch. The indexed column is a text field and
data consists of mix of Japanese, alphanumeri
On Thu, May 30, 2013 at 11:47 PM, Robert Haas wrote:
> On Wed, May 29, 2013 at 10:51 PM, Amit Langote
> wrote:
>> So, it appears, for search strings consisting of 2 (or < 3)
>> characters, trigrams can not be utilized. No?
>
> I think that's right. &qu
n its CRC
(due to its problems in partial matching) as GIN key (?) has not been
implemented into pg_trgm yet, right? And even though, such a facility
would be added, we would still need to handle multibyte characters
case differently (even for partial matching), is that right?
--
Amit Langote
arch term that causes
trigrams (stored in the index if answer to (1) is yes) NOT to be used
in such a partial matching case?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jun 1, 2013 at 1:48 AM, Sawada Masahiko wrote:
> On Fri, May 31, 2013 at 11:16 AM, Amit Langote
> wrote:
>> 2) And if that is so, is there problem in gin_extract_query_trgm(),
>> that is while generating trigrams from a query search term that causes
>> trigrams
Hello,
At what point do the entries in the pending list are moved to the main
GIN data structure?
>From documentation, I read that overflowing work_mem and vacuum are
two such causes; what about when the concerned backend is to exit and
autovacuum has not yet kicked in?
--
Amit Lang
On Fri, Jun 7, 2013 at 11:15 PM, Robert Haas wrote:
> On Wed, Jun 5, 2013 at 10:06 PM, Amit Langote wrote:
>> At what point do the entries in the pending list are moved to the main
>> GIN data structure?
>> From documentation, I read that overflowing work_mem and vacuum a
On Fri, Jun 7, 2013 at 11:36 PM, Andres Freund wrote:
> On 2013-06-07 23:28:56 +0900, Amit Langote wrote:
>> On Fri, Jun 7, 2013 at 11:15 PM, Robert Haas wrote:
>> > On Wed, Jun 5, 2013 at 10:06 PM, Amit Langote
>> > wrote:
>> >> At what point do the e
g_config
make USE_PGXS=1 PG_CONFIG=/path/to/pg_config install
When user does not work with pg source directly and does not have
postgresql-contrib installed?
Am I missing something here?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
updesc
*/
if (attnum > tupleDesc->natts)
return true;
Attached patch fixes this.
--
Amit Langote
correct-a-comment-in-heaptupledotc.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jun 18, 2013 at 6:01 PM, Andres Freund wrote:
> Hi,
>
> On 2013-06-18 17:56:34 +0900, Amit Langote wrote:
>> Should it be: "return true if attnum is out of range according to the
>> tupdesc" instead of "return NULL if attnum is out of range accordi
wo co-exist) and vice versa. It would be
nice if we had the above feature so that pg_bigm or pg_trgm can use
'IF NOT EXISTS' while creating pg_trgm_ops operator class.
Thoughts?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 20, 2013 at 9:48 PM, Fabrízio de Royes Mello
wrote:
>
> On Thu, Jun 20, 2013 at 1:52 AM, Amit Langote
> wrote:
>>
>> Is it possible to:
>>
>> CREATE [ OR REPLACE | IF NOT EXISTS ] OPERATOR CLASS
>>
>> I am in a situation where I need to co
= 'slave2'
> synchronous_transfer = all
> wal_sender_timeout = 50
> ---
>
Just ask to clarify:
Is 'slave2' a failback standby?
What does 'synchronous_transfer = all' mean? Does that mean wait
during both commit and checkpoint?
--
Amit L
meline history file in
archive before it starts replaying any WAL?
* And, would the new master, before forking the WAL, replay all the
WAL that is necessary to come to state (of data directory) that the
old master was just before it crashed?
Am I missing something here?
--
Amit Langote
--
Sent
t in this iteration.
Has anything of this kind been encountered/reported before?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Jun 27, 2013 at 12:02 AM, Alvaro Herrera
wrote:
> Amit Langote escribió:
>
>> The segfault in question happens at line 1141:
>>
>> off = att_align_pointer(off, thisatt->attalign, -1, tp + off);
>>
>> char *tp; /*
On Thu, Jun 27, 2013 at 12:02 AM, Alvaro Herrera
wrote:
> Amit Langote escribió:
>
>> The segfault in question happens at line 1141:
>>
>> off = att_align_pointer(off, thisatt->attalign, -1, tp + off);
>>
>> char *tp; /*
>
You could start here:
http://www.postgresql.org/docs/9.2/static/wal-intro.html
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
anyway. Does that make
sense?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jul 23, 2013 at 1:11 PM, Amit Langote wrote:
> Hello,
>
> While understanding the effect of maintenance_work_mem on time taken
> by CREATE INDEX, I observed that for the values of
> maintenance_work_mem less than the value for which an internal sort is
> performed,
On Wed, Jul 24, 2013 at 6:02 AM, Jeff Janes wrote:
> On Tue, Jul 23, 2013 at 1:23 AM, Amit Langote wrote:
>> On Tue, Jul 23, 2013 at 1:11 PM, Amit Langote
>> wrote:
>>> Hello,
>>>
>>> While understanding the effect of maintenance_work_mem on time take
On Wed, Jul 24, 2013 at 11:30 AM, Amit Langote wrote:
> On Wed, Jul 24, 2013 at 6:02 AM, Jeff Janes wrote:
>> If you are using trace_sort to report that, it reports the switch as
>> happening as soon as it runs out of memory.
>>
>> At point, all we have been doing is
On Wed, Jul 24, 2013 at 3:20 AM, Jeff Janes wrote:
> On Mon, Jul 22, 2013 at 9:11 PM, Amit Langote wrote:
>> Hello,
>>
>> While understanding the effect of maintenance_work_mem on time taken
>> by CREATE INDEX, I observed that for the values of
>> maintenance
Hi Jeff,
On Tue, Jul 30, 2013 at 3:25 AM, Jeff Janes wrote:
> On Tue, Jul 23, 2013 at 10:56 PM, Amit Langote
> wrote:
>> On Wed, Jul 24, 2013 at 3:20 AM, Jeff Janes wrote:
>>>
>>> The heap structure used in external sorts is cache-unfriendly. The
>>&
extcol5) from table where octet_length(textcol5) >
800;
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
stgresMain (argc=,
argv=, dbname=0x12e8f50 "template1",
username=)
at postgres.c:3990
#13 0x005d58c7 in main (argc=9, argv=0x12cd330) at main.c:192
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Build using:
CFLAGS="-g -O0" ./configure --with-pam --enable-cassert --enable-debug
--prefix=/home/amit/dev/pginstall/
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Aug 1, 2013 at 3:52 PM, Amit Langote wrote:
> Build using:
> CFLAGS="-g -O0" ./configure --with-pam --enable-cassert --enable-debug
> --prefix=/home/amit/dev/pginstall/
>
> --
> Amit Langote
Umm, I guess I forgot to "make clean" before building with
"pgbench -i -s 3500" would be.
May the routines in fd.c become bottleneck with a large number of
concurrent connections to above database, say something like "pgbench
-j 8 -c 128"? Is there any other place I should be paying attention
to?
--
Amit Langote
--
Sent via pgsql-
On Mon, Aug 5, 2013 at 5:01 PM, KONDO Mitsumasa
wrote:
> Hi Amit,
>
>
> (2013/08/05 15:23), Amit Langote wrote:
>>
>> May the routines in fd.c become bottleneck with a large number of
>> concurrent connections to above database, say something like "pgbench
On 10-03-2015 PM 01:09, Amit Kapila wrote:
> On Tue, Mar 10, 2015 at 6:50 AM, Haribabu Kommi
>> Is this patch handles the cases where the re-scan starts without
>> finishing the earlier scan?
>>
>
> Do you mean to say cases like ANTI, SEMI Join (in nodeNestLoop.c)
> where we scan the next outer t
On 13-03-2015 AM 10:24, Amit Kapila wrote:
> On Thu, Mar 12, 2015 at 4:22 PM, Amit Langote
>> From Robert's description[1], it looked like the NestLoop with Funnel
> would
>> have Funnel as either outer plan or topmost plan node or NOT a
> parameterised
>> pla
On 13-03-2015 PM 01:37, Amit Langote wrote:
> By the way, is it right that TupleQueueFunnel.queue has one shm_mq_handle per
> initialized parallel worker? If so, how does TupleQueueFunnel.maxqueues relate
> to ParallelContext.nworkers (of the corresponding parallel context)?
>
> W
On 12-03-2015 PM 11:46, Amit Kapila wrote:
> [parallel_seqscan_v10.patch]
There may be a bug in TupleQueueFunnelNext().
1) I observed a hang with stack looking like:
#0 0x0039696df098 in poll () from /lib64/libc.so.6
#1 0x006f1c6a in WaitLatchOrSocket (latch=0x7f29dc3c73b4,
wakeEve
On 13-03-2015 PM 05:32, Amit Langote wrote:
> On 12-03-2015 PM 11:46, Amit Kapila wrote:
>> [parallel_seqscan_v10.patch]
>
> There may be a bug in TupleQueueFunnelNext().
>
> 1) I observed a hang with stack looking like:
>
> #0 0x0039696df098 in poll ()
On Fri, Mar 13, 2015 at 11:03 PM, Amit Kapila wrote:
> On Fri, Mar 13, 2015 at 7:15 PM, Robert Haas wrote:
>>
>> On Fri, Mar 13, 2015 at 7:01 AM, Amit Kapila
>> wrote:
>> > I think this can happen if funnel->nextqueue is greater than
>> > funnel->nqueues.
>> > Please see if attached patch fixes
On 13-03-2015 PM 11:03, Amit Kapila wrote:
> On Fri, Mar 13, 2015 at 7:15 PM, Robert Haas wrote:
>>
>> I don't think this is the right fix; the point of that code is to
>> remove a tuple queue from the funnel when it gets detached, which is a
>> correct thing to want to do. funnel->nextqueue shou
On 16-03-2015 PM 04:14, Amit Kapila wrote:
> On Mon, Mar 16, 2015 at 9:40 AM, Amit Langote
> wrote:
>> Or if the just-detached queue happens to be the last one, we'll make
>> shm_mq_receive() to read from a potentially already-detached queue in the
>> immediately n
On 20-03-2015 PM 09:06, Amit Kapila wrote:
> On Mon, Mar 16, 2015 at 12:58 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp> wrote:
>> Actually I meant "currently the last" or:
>>
>> funnel->nextqueue == funnel->nqueue - 1
>>
>> S
On Wednesday, March 25, 2015, Michael Paquier wrote:
>
> On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote:
> > The index is unlogged until reindexing...
> >
> > [...]
> > Which is think also raises the question, why are unlogged indexes made
> > persistent by a reindex?
>
> That's a bug of HEAD,
On Wednesday, March 25, 2015, Thom Brown wrote:
> On 25 March 2015 at 12:22, Amit Langote > wrote:
>
>> On Wednesday, March 25, 2015, Michael Paquier > > wrote:
>> >
>> > On Tue, Mar 24, 2015 at 8:46 PM, Thom Brown wrote:
>&g
On 02-04-2015 AM 09:24, Jim Nasby wrote:
> The other potential advantage (and I have to think this could be a BIG
> advantage) is extending by a large amount makes it more likely you'll get
> contiguous blocks on the storage. That's going to make a big difference for
> SeqScan speed. It'd be intere
Hi,
Attached does:
Index childRTindex;
AppendRelInfo *appinfo;
-/* Open rel if needed; we already have required locks */
+/* Open rel if needed; we already have acquired locks */
if (childOID != parentOID)
newrelation = heap_open(childOID, NoLock);
else
On 03-04-2015 PM 03:58, Amit Langote wrote:
> Index childRTindex;
> AppendRelInfo *appinfo;
>
> -/* Open rel if needed; we already have required locks */
> +/* Open rel if needed; we already have acquired locks */
> if (childOID != parentOID)
>
Hi,
Attached fixes what I suppose is a typo:
* so set up a single dummy path for it. Here we only check this for
* regular baserels; if it's an otherrel, CE was already checked in
-* set_append_rel_pathlist().
+* set_append_rel_size().
*
Thanks,
Amit
On 08-04-2015 PM 12:46, Amit Kapila wrote:
> Going forward, I think we can improve the same if we decide not to shutdown
> parallel workers till postmaster shutdown once they are started and
> then just allocate them during executor-start phase.
>
I wonder if it makes sense to invent the notion o
On 16-04-2015 PM 07:50, Etsuro Fujita wrote:
>> The EXPLAIN output has also been improved as discussed in [1].
>
> I noticed that the EXPLAIN for a pushed-down update (delete) on inheritance
> childs doubly displays "Foreign Update" ("Foreign Delete"), one for
> ForeignScan and the other for Modif
Fujita-san,
On 16-04-2015 PM 08:40, Etsuro Fujita wrote:
>> From what I see in Tom's commit message[0] for FTI patch, this shouldn't be,
>> right?
>>
>> To be specific, there should be "Foreign Scan" there as per the commit. Am I
>> missing something?
>
> As shown in the below example, this patc
On 17-04-2015 PM 12:35, Etsuro Fujita wrote:
> On 2015/04/17 10:23, Amit Langote wrote:
>> By the way, one suggestion may be to attach a "(pushed down)" to the
>> ModifyTable's "Foreign Update". And in that case, there would be no mention
>> of
>&g
On 2015-04-21 AM 03:29, Robert Haas wrote:
> On Wed, Apr 8, 2015 at 3:38 AM, Amit Langote wrote:
>> On 08-04-2015 PM 12:46, Amit Kapila wrote:
>>> Going forward, I think we can improve the same if we decide not to shutdown
>>> parallel workers till postmaster shutdow
On 2015-04-25 AM 04:20, Tom Lane wrote: *
>
> It's not a typo; the comment was correct when written. But I evidently
> missed updating it when set_append_rel_pathlist() got split into two
> functions. Applied, thanks for noticing!
>
Ah, thanks!
Amit
--
Sent via pgsql-hackers mail
On 2015-04-22 AM 04:14, Robert Haas wrote:
>
> We should check IsParallelWorker() for operations that are allowed in
> the master during parallel mode, but not allowed in the workers - e.g.
> the master can scan its own temporary relations, but its workers
> can't. We should check IsInParallelMod
Hi,
Following ALTER TABLE actions are applied recursively to inheritance
descendents via ATSimpleRecursion() -
ALTER COLUMN DEFAULT
ALTER COLUMN DROP NOT NULL
ALTER COLUMN SET NOT NULL
ALTER COLUMN SET STATISTICS
ALTER COLUMN SET STORAGE
The code at the beginning of ATSimpleRecursion() looks li
On Tue, Apr 28, 2015 at 8:45 PM, Etsuro Fujita
wrote:
> On 2015/04/28 15:17, Amit Langote wrote:
>
> Yeah, I think we should now allow the recursion for inheritance parents that
> are foreign tables as well. Attached is a patch for that.
>
Thanks!
>> An example,
>&g
On Tue, Apr 28, 2015 at 9:28 PM, David Fetter wrote:
> On Tue, Apr 28, 2015 at 03:17:08PM +0900, Amit Langote wrote:
>>
>> An example,
>> postgres=# alter foreign table fparent alter a type char;
>> ALTER FOREIGN TABLE
>>
>> postgres=# select * from fparen
Hi,
Attached does:
s/pg_replication_origin_xact-setup/pg_replication_origin_xact_setup/g
or, (s/-/_/g)
Thanks,
Amit
diff --git a/doc/src/sgml/replication-origins.sgml b/doc/src/sgml/replication-origins.sgml
index c531022..0cd08ee 100644
--- a/doc/src/sgml/replication-origins.sgml
+++ b/doc/src/
On 2015-05-07 PM 11:49, Rui Hai Jiang wrote:
>
> I'm trying to figure out when the following functions are called,
>
> charin()
> int2in()
> int4in()
> textin()
>
> create table abcin( id integer, name varchar(10), title text);
> insert into abcin( id, name, title ) values (1,'tom', 'manager
Hi,
Commit 63f1ccd got rid of src/tool/backend and hence
src/tool/backend/index.html. But lmgr README still directs reader to the
aforementioned file. Attached removes this obsolete reference.
Thanks,
Amit
diff --git a/src/backend/storage/lmgr/README b/src/backend/storage/lmgr/README
index 6bc7ef
Hi,
Commit 63f1ccd got rid of src/tool/backend and hence
src/tool/backend/index.html. But lmgr README still directs reader to the
aforementioned file. Attached removes this obsolete reference.
Thanks,
Amit
diff --git a/src/backend/storage/lmgr/README b/src/backend/storage/lmgr/README
index 6bc7e
On Friday, May 8, 2015, Amit Langote wrote:
>
> Hi,
>
> Commit 63f1ccd got rid of src/tool/backend and hence
> src/tool/backend/index.html. But lmgr README still directs reader to the
> aforementioned file. Attached removes this obsolete reference.
>
Please ignore this.
On 2015-05-15 AM 05:01, Pavel Stehule wrote:
>
> I am trying to start bgworker from bgworker and create communication
> between these process. I have a code based on test_shm_mq. This code fails
> because BackendPidGetProc doesn't find related bgworker process, although
> the registrant process is
On 2015-05-15 AM 10:39, Amit Langote wrote:
> On 2015-05-15 AM 05:01, Pavel Stehule wrote:
>>
>> I am trying to start bgworker from bgworker and create communication
>> between these process. I have a code based on test_shm_mq. This code fails
>> because BackendPidG
On 2015-05-15 AM 10:59, Amit Langote wrote:
> On 2015-05-15 AM 10:39, Amit Langote wrote:
>> On 2015-05-15 AM 05:01, Pavel Stehule wrote:
>>>
>>> I am trying to start bgworker from bgworker and create communication
>>> between these process. I have a code b
On 2015-05-15 PM 02:13, Pavel Stehule wrote:
> 2015-05-15 3:39 GMT+02:00 Amit Langote :
>> One reason for this may be that the worker was not started with the flag
>> BGWORKER_SHMEM_ACCESS which is necessary to perform InitProcess() that
>> would
>> initialize a PGPROC
On Sat, Aug 30, 2014 at 12:56 AM, Alvaro Herrera
wrote:
> Prompted by a comment in the UPDATE/LIMIT thread, I saw Marko Tiikkaja
> reference Tom's post
> http://www.postgresql.org/message-id/1598.1399826...@sss.pgh.pa.us
> which mentions the possibility of a different partitioning
> implementation
Hi,
I tend to agree with Robert that partitioning should continue using
inheritance based implementation. In addition to his point about reinventing
things it could be pointed out that there are discussions/proposals elsewhere
about building foreign table inheritance capability; having partitionin
801 - 900 of 1334 matches
Mail list logo
