Re: [HACKERS] WIP: Aggregation push-down

Antonin Houska <a...@cybertec.at> wrote: > This is another version of the patch. > shard.tgz demonstrates the typical postgres_fdw use case. One query shows base > scans of base relation's partitions being pushed to shard nodes, the other > pushes down a join and performs aggre

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

et_append_rel_size() is called too early to find out how many child paths will eventually exist if Append represents a join of a partitioned table. I think the partition matching takes place at later stage and that determines the actual number of partitions, and therefore the number of Append subpaths.

Re: [HACKERS] WIP: Separate log file for extension

Magnus Hagander <mag...@hagander.net> wrote: > > On Fri, Aug 25, 2017 at 12:12 AM, Antonin Houska <a...@cybertec.at> wrote: > > I like this idea in general. > > Then it's supposed to change some of its attributes > > > adjust_log_s

Re: [HACKERS] WIP: Separate log file for extension

Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > On 08/28/2017 11:23 AM, Antonin Houska wrote: > > Craig Ringer <cr...@2ndquadrant.com> wrote: > > > >> On 25 August 2017 at 15:12, Antonin Houska <a...@cybertec.at> wrote: > >> > >> H

Re: [HACKERS] WIP: Aggregation push-down

Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Thu, Aug 17, 2017 at 8:52 PM, Antonin Houska <a...@cybertec.at> wrote: > > Antonin Houska <a...@cybertec.at> wrote: > > > >> Antonin Houska <a...@cybertec.at> wrote: > >> &g

Re: [HACKERS] WIP: Aggregation push-down

views of the partch may result in a major rework. And if large parts of the code will have to be wasted, some / many TODOs will be gone as well. > Thanks > > On Thu, Aug 17, 2017 at 8:52 PM, Antonin Houska <a...@cybertec.at> wrote: > > Antonin Houska <a...@cybertec.at&g

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

m make_join_rel(): * build_join_rel -> build_joinrel_partition_info -> partition_bounds_merge * try_partition_wise_join -> partition_bounds_merge Is this intentional, or just a thinko? -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Fri, Sep 1, 2017 at 6:05 PM, Antonin Houska <a...@cybertec.at> wrote: > > > > > > > > * get_partitioned_child_rels_for_join() > > > > I think the Assert() statement is easier to

Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised

of the loop because elapsed_min does not have to be re-computed each time: /* How much should have elapsed at minimum? */ elapsed_min = elapsed_min_unit * (throttling_counter / throttling_sample); And also a comment explaining the purpose of the loop would be appreciated. Thanks. -- Antoni

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

I don't think there's a reason not to join a_0 partition to b_0, is there? -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at diff --git a/src/backend/optimizer/plan/planner.c b/src/backen

Re: [HACKERS] WIP: Separate log file for extension

Masahiko Sawada <sawada.m...@gmail.com> wrote: > On Fri, Aug 25, 2017 at 4:12 PM, Antonin Houska <a...@cybertec.at> wrote: > > Attached is a draft patch to allow extension to write log messages to a > > separate file. > > Does it allow postgres core code to w

[HACKERS] Write operations in parallel mode

), errmsg("cannot update tuples during a parallel operation"))); -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list

Re: [HACKERS] WIP: Separate log file for extension

Craig Ringer <cr...@2ndquadrant.com> wrote: > On 25 August 2017 at 15:12, Antonin Houska <a...@cybertec.at> wrote: > > How will this play with syslog? csvlog? etc? There's nothing special about csvlog: the LogStream structure has a "destination" field, so if parti

[HACKERS] WIP: Separate log file for extension

ism makes initialization of the log streams by postmaster child processes non-trivial. I decided to extend save_backend_variables() and restore_backend_variables() accordingly. Maybe someone has better idea. pgaudit seems to be the most obvious use case for this enhancement, but it might be use

Re: [HACKERS] WIP: Aggregation push-down

Antonin Houska <a...@cybertec.at> wrote: > Antonin Houska <a...@cybertec.at> wrote: > > > This is a new version of the patch I presented in [1]. > > Rebased. > > cat .git/refs/heads/master > b9a3ef55b253d885081c2d0e9dc45802cab71c7b This is another versi

[HACKERS] Unused field of ProjectionPath

an; On the other hand, if the targetlists can also be different at path creation time and equal at plan creation time, the lists do always need comparison at plan creation time and the dummypp field should probably be removed. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26

Re: [HACKERS] asynchronous execution

ng_async[hidx] = tail; } ++hidx; } estate->es_num_pending_async = hidx; } And besides that, I think it'd be more intuitive if the meaning of "head" and

Re: [HACKERS] asynchronous execution

quest state is being set to ASYNCREQ_COMPLETE. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make change

Re: [HACKERS] asynchronous execution

the planner should ensure that executor does not fire the assertion statement above. The script attached shows an example how to cause the assertion failure. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http:/

Re: [HACKERS] snapbuild woes

GetOldestSafeDecodingTransactionId(!need_full_snapshot); (If so, I think "considerCatalog" argument name would be clearer than "catalogOnly".) -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, htt

Re: [HACKERS] Partition-wise aggregation/grouping

Jeevan Chalke <jeevan.cha...@enterprisedb.com> wrote: > On Thu, Apr 27, 2017 at 4:53 PM, Antonin Houska <a...@cybertec.at> wrote: > > > Robert Haas <robertmh...@gmail.com> wrote: > > > Well, I'm confused. I see that there's a relationship between what > &

Re: [HACKERS] Partition-wise aggregation/grouping

Antonin Houska <a...@cybertec.at> wrote: > > Jeevan Chalke <jeevan.cha...@enterprisedb.com> wrote: > > > Our work will overlap when we are pushing down the aggregate on partitioned > > base relation to its children/partitions. > > > > I thin

Re: [HACKERS] Partition-wise aggregation/grouping

The promised new version of my patch is here: https://www.postgresql.org/message-id/9666.1491295317%40localhost Jeevan Chalke <jeevan.cha...@enterprisedb.com> wrote: > On Tue, Mar 21, 2017 at 1:47 PM, Antonin Houska <a...@cybertec.at> wrote: > > Jeevan Chalke <jeevan

Re: [HACKERS] Partition-wise aggregation/grouping

the result of both base relation scans and joins. I'm trying hard to make the next version available before an urgent vacation that I'll have to take at random date between today and early April. I suggest that we coordinate the effort, it's lot of work in any case. -- Antonin Houska Cybertec Schönig

Re: [HACKERS] Parameterization of partial path

Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Feb 9, 2017 at 12:36 PM, Antonin Houska <a...@cybertec.at> wrote: > > When looking at try_partial_hashjoin_path and try_partial_nestloop_path > > functions I'm failing to understand the comment "Parameterized par

[HACKERS] Parameterization of partial path

dn't try_partial_hashjoin_path and try_partial_nestloop_path do just the same checks that try_hashjoin_path and try_nestloop_path do respectively? -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- S

Re: [HACKERS] pg_bsd_indent: implement -lps ("leave preprocessor space")

atting can be implemented in elisp and added to src/tools/editors/emacs.samples. In particular I mean one function to make the code human readable and another one to turn it back to the concise style. User would only call the function on text selection (region) as opposed to the whole file. -- Antonin H

Re: [HACKERS] asynchronous execution

_fdw nodes of Append plan on the same remote server. I expect that these "co-located" nodes would currently use the same user mapping and therefore the same connection. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgr

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

" point of view - the relation uniqueness also needs to be checked against the GROUP BY clause. Thus the "unique keys" concept seem to me like an useful abstraction. Does this proposal seem to have a serious flaw? [1] https://www.postgresql.org/message-id/CAKJS1f_h1CLff92B%3D%2BbdrM

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

oolinner_unique; /* inner side of join matches no more than one * outer side tuple */ -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.d

Re: [HACKERS] PoC: Grouped base relation

David Rowley <david.row...@2ndquadrant.com> wrote: > On 20 January 2017 at 00:22, Antonin Houska <a...@cybertec.at> wrote: > > Sorry, it was my thinko - I somehow confused David's CROSS JOIN example with > > this one. If one side of the join clause is unique and the o

Re: [HACKERS] PoC: Grouped base relation

there might be some usecases which could benefit without > >> solving this problem. > > > > If "combining aggregates ..." refers to joining grouped relations, then I > > insist on doing this in the initial version of the new feature too. > > Otherwi

Re: [HACKERS] PoC: Grouped base relation

Antonin Houska <a...@cybertec.at> wrote: Well, the following one does not seem to be a typical example. I could generate the plan, but now I think that the aggregation push down does not in general decrease the number of groups the final aggregation has to process. Maybe I just hit p

Re: [HACKERS] PoC: Grouped base relation

Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > On 01/17/2017 08:05 PM, Antonin Houska wrote: > > Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > > > > > >> Another thing is that in my experience most queries do joins on foreign > >>

Re: [HACKERS] PoC: Grouped base relation

[ Trying to respond to both Tomas and David. I'll check tomorrow if anything else of the thread needs my comment. ] Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > On 01/17/2017 12:42 AM, David Rowley wrote: > > On 10 January 2017 at 06:56, Antonin Houska <a...@cybertec.at

Re: [HACKERS] PoC: Grouped base relation

it can be computed. I think this can be achieved by adding extra aggregation nodes to the join tree. As I still anticipate more important design changes, this part is not at the top of my TODO list. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt

Re: [HACKERS] Slow I/O can break throttling of base backup

Antonin Houska <a...@cybertec.at> wrote: > It seems to be my bug. I'll check tomorrow. I could reproduce the problem by adding sufficient sleep time to the loop. > Magnus Hagander <mag...@hagander.net> wrote: >> I wonder if the else if (sleep > 0) at the botto

Re: [HACKERS] Slow I/O can break throttling of base backup

where we never recover, and thus never > end up sleeping ever again, effectively turning off rate limiting. > > I wonder if the else if (sleep > 0) at the bottom of throttle() should just > be a simple else and always run, resetting last_throttle? > > -- > Magnus Hagander >

[HACKERS] Possibly too stringent Assert() in b-tree code

mp, but I remember all the fields of PageHeader were indeed zeroed. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

[HACKERS] Unused function arguments

use and which ones can be removed. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscrip

Re: [HACKERS] Question about MVCC-unsafe commands

Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Aug 23, 2016 at 10:10 AM, Antonin Houska <a...@cybertec.at> wrote: > CLUSTER preserves xmin/xmax when rewriting, but ALTER TABLE does not. Indeed, CLUSTER was the command I picked for my experiments. I didn't expect such a

[HACKERS] Question about MVCC-unsafe commands

rewriting changes neither table contents, nor visibility. Can anyone explain what I miss? [1] https://www.postgresql.org/docs/9.6/static/mvcc-caveats.html -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://w

[HACKERS] Typos in logical decoding

to me like a thinko. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at diff --git a/src/backend/replication/logical/logical.c b/src/backend/replication/logical/logical.c new file mode 10

Re: [HACKERS] UNIQUE capability to hash indexes

that I see the problem mentioned again, I feel myself kind of "ignited". I expect to have some leisure time at the end of February, so I'll test the patch and post my results early in March. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web

Re: [HACKERS] Bitmap index scans use of filters on available columns

ental reason the filter on y is not being applied to > the index scan, rather than the heap scan? -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing

[HACKERS] Non-volatile variables used for spinlock manipulation

Since SpinLockAcquire() / SpinLockRelease() macros usually reference variables declared as volatile, I wonder if the following changes should be applied. -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de,

Re: [HACKERS] Thinko in processing of SHM message size info?

Robert Haas robertmh...@gmail.com wrote: On Thu, Aug 6, 2015 at 1:24 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Aug 6, 2015 at 9:04 AM, Antonin Houska a...@cybertec.at wrote: Can anyone please explain why the following patch shouldn't be applied? diff --git a/src/backend/storage

Re: [HACKERS] Race conditions in shm_mq.c

Robert Haas robertmh...@gmail.com wrote: On Thu, Aug 6, 2015 at 2:38 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Aug 6, 2015 at 10:10 AM, Antonin Houska a...@cybertec.at wrote: During my experiments with parallel workers I sometimes saw the master and worker process blocked

[HACKERS] Thinko in processing of SHM message size info?

anything should be subtracted. Note that the previous iteration must have called shm_mq_inc_bytes_read(), so rb should not include anything of mqh-mqh_partial_bytes. Thanks. -- Antonin Houska Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de

[HACKERS] Race conditions in shm_mq.c

has effectively missed the receiver's notification and called WaitLatch() too (if the receiver already waits on its latch, it does not help for sender to call shm_mq_notify_receiver(): receiver won't do anything because there's no new data in the queue). Below is my patch proposal. -- Antonin

Re: [HACKERS] Parallel Seq Scan

. BTW, emacs shows whitespace on otherwise empty line parallelpath.c:57. -- Antonin Houska Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

[HACKERS] Possible gaps/garbage in the output of XLOG reader

if the callback always reads XLOG_BLCKSZ bytes, but in fact only *reqLen* is the mandatory size of the chunk delivered. There are probably various ways to fix this problem. Attached is what I did in my environment. I hit the problem on 9.4.1, but the patch seems to apply to master too. -- Antonin

[HACKERS] Concurrent calls of _hash_getnewbuf()

be introduced and used and used in both cases? [1] http://www.postgresql.org/message-id/32423.1427413442@localhost -- Antonin Houska Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at diff --git a/src/backend

Re: [HACKERS] WIP: Split of hash index bucket

Antonin Houska a...@cybertec.at wrote: I'm still testing it. especially the concurrent access. There are probably bugs in the code, but it can help understand what I mean. I've traced the most important cases of concurrent insertion into a bucket split of which is in progress. A few related

[HACKERS] WIP: Split of hash index bucket

-- Antonin Houska Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at diff --git a/src/backend/access/hash/hash.c b/src/backend/access/hash/hash.c new file mode 100644 index 24b06a5..149bbcf *** a/src/backend

Re: [HACKERS] Corner case for add_path_precheck

Tom Lane t...@sss.pgh.pa.us wrote: Antonin Houska a...@cybertec.at writes: The special case is that the path passed to add_path_precheck() has costs *equal to* those of the old_path. If pathkeys, outer rells and costs are the same, as summarized in the comment above, I expect

[HACKERS] Corner case for add_path_precheck

, as opposed to the fuzzy comparison?) -- Antonin Houska Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] memory explosion on planning complex query

? -- Antonin Houska Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

[HACKERS] pg_class(relpersistence) of hash index

'; relpersistence p (1 row) -- Antonin Houska Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] some ideas from users

On 11/22/2014 12:24 PM, Marko Tiikkaja wrote: On 2014-11-22 12:20 PM, Pavel Stehule wrote: 2. missing table function with all settings. Like SHOW ALL, but with filtering possibility What's wrong with pg_settings? Do you mean pg_show_all_settings() ? -- Antonin Houska Cybertec Schönig

Re: [HACKERS] Functions used in index definitions shouldn't be changed

definitions, specifically altering strictness. Attached is a patch implementing a fix. Instead of adding extra check, shouldn't you just ensure that DEPENDENCY_INTERNAL is the dependency type and let the existing logic do the work? -- Antonin Houska Cybertec Schönig Schönig GmbH Gröhrmühlgasse

Re: [HACKERS] Unintended restart after recovery error

to postmaster. -- Antonin Houska Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] array exclusion constraints

the difficulties: http://www.postgresql.org/message-id/5297dc17.7000...@proxel.se -- Antonin Houska Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

[HACKERS] Unintended restart after recovery error

)); continue; -- Antonin Houska Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de, http://www.cybertec.at -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Unintended restart after recovery error

Antonin Houska a...@cybertec.at wrote: While looking at postmaster.c:reaper(), one problematic case occurred to me. 1. Startup process signals PMSIGNAL_RECOVERY_STARTED. 2. Checkpointer process is forked and immediately dies. 3. reaper() catches this failure, calls HandleChildCrash

Re: [HACKERS] Unintended restart after recovery error

Fujii Masao masao.fu...@gmail.com wrote: On Wed, Nov 12, 2014 at 6:52 PM, Antonin Houska a...@cybertec.at wrote: While looking at postmaster.c:reaper(), one problematic case occurred to me. 1. Startup process signals PMSIGNAL_RECOVERY_STARTED. 2. Checkpointer process is forked

Re: [HACKERS] Convert query plan to sql query

mariem mariem.benfad...@gmail.com wrote: Hello, I would like to transform the query plan (output of the planner, debug_print_plan) into an sql query. I don't think SQL can express the information the plan contains. For example, join methods (hash, nest loop, merge). -- Antonin Houska

Re: [HACKERS] from_collapse_limit considerations

[ I think I responded earlier but don't see my mail in the archive... ] Tom Lane t...@sss.pgh.pa.us wrote: Antonin Houska a...@cybertec.at writes: I noticed that - unlike join_collapse_limit - the from_collapse_limit does not enforce maximum length of the top-level list. Shouldn't it do

[HACKERS] from_collapse_limit considerations

the original list (but not the contained items). */ + list_free(result); + + /* Replace the list with folded one. */ + result = fromlist_new; + } + + return result; +} + + /* * make_outerjoininfo * Build a SpecialJoinInfo for the current outer join -- Antonin Houska Cybertec Schönig Schönig

[HACKERS] Another logical decoding assertion failure

http://www.postgresql.org/message-id/blu436-smtp12682d628f61ab9736099c3dc...@phx.gbl recalls me that I also saw an assertion failure recently. Although I wanted to isolate and report my issue when my vacation is over, this report made me curious whether I saw the same. Eventually it seems to be a

Re: [HACKERS] Another logical decoding assertion failure

On 08/15/2014 03:16 PM, Andres Freund wrote: On 2014-08-15 14:53:45 +0200, Antonin Houska wrote: postgres=# SELECT pg_create_logical_replication_slot('my_slot', 'test_decoding'); pg_create_logical_replication_slot (my_slot,0/16F3B30) (1 row) postgres

[HACKERS] Review: ECPG FETCH readahead

I haven't been too familiar with the ECPG internals so far but tried to do my best. Generic criteria * Does it follow the project coding guidelines? Yes. * Are there portability issues? Shouldn't be. I even noticed the code tries to avoid platform-specific behaviour of

Re: [HACKERS] Review: ECPG FETCH readahead

[Now I'm only replying where my explanation seems useful. If you expect anything else, please remind me.] On 04/23/2014 06:41 PM, Boszormenyi Zoltan wrote: All exported ECPG functions returns bool. IIRC the code generated by EXEC SQL WHENEVER something-else-than-CONTINUE makes use of the

Re: [HACKERS] Review: ECPG FETCH readahead

On 04/23/2014 05:24 PM, Alvaro Herrera wrote: Antonin Houska wrote: I haven't been too familiar with the ECPG internals so far but tried to do my best. I'm afraid we're stuck on this patch until Michael has time to review it, or some other committer wants to acquire maintainership rights

Re: [HACKERS] Proposal: fix range queries in btree_gin

this. This reminds me of my earlier experiment http://www.postgresql.org/message-id/51fbc99d.7040...@gmail.com even though my motivation was different: to make comparePartial() support function unnecessary. // Antonin Houska (Tony) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Comment - uniqueness of relfilenode

On 03/06/2014 04:33 AM, Robert Haas wrote: On Wed, Mar 5, 2014 at 8:54 PM, Bruce Momjian br...@momjian.us wrote: On Mon, Nov 11, 2013 at 05:48:52PM +0100, Antonin Houska wrote: On 11/10/2013 12:57 AM, Robert Haas wrote: On Thu, Nov 7, 2013 at 10:56 AM, Antonin Houska antonin.hou...@gmail.com

Re: [HACKERS] Equivalence Rules

in the original query) do not change the semantics. (As for set operations, someone else needs to explain.) // Antonin Houska (Tony) On 03/02/2014 09:02 AM, Ali Piroozi wrote: Hi My question is: Does PostgreSQL implements equivalence rules(from those are listed in email's attachment

Re: [HACKERS] Backup throttling

On 02/27/2014 11:04 PM, Alvaro Herrera wrote: I pushed this patch with a few further tweaks. In your changes to address the above point, you made the suffix mandatory in the pg_basebackup -r option. This seemed a strange restriction, so I removed it. It seems more user-friendly to me to

Re: [HACKERS] Backup throttling

basebackup.c sensitive to PM death? // Antonin Houska (Tony) diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index 832524e..704b653 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -1772,7 +1772,7 @@ The commands accepted in walsender mode

[HACKERS] bgworker crashed or not?

no success). Do we need my patch, my patch + something for the handler or no patch at all? // Antonin Houska (Tony) diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c index 0957e91..0313fd7 100644 --- a/src/backend/postmaster/postmaster.c +++ b/src/backend

Re: [HACKERS] Backup throttling

05:10 PM, Antonin Houska wrote: On 01/15/2014 10:52 PM, Alvaro Herrera wrote: I gave this patch a look. There was a bug that the final bounds check for int32 range was not done when there was no suffix, so in effect you could pass numbers larger than UINT_MAX and pg_basebackup would

Re: [HACKERS] Backup throttling

. It was probably too generic, THROTTLING_SAMPLE_MIN is no longer there. New patch version is attached. // Antonin Houska (Tony) diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index 7d99976..799d214 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml

[HACKERS] Assertion failure in base backup code path

in ServerLoop () at postmaster.c:1585 #14 0x00713370 in PostmasterMain (argc=3, argv=0x2381f60) at postmaster.c:1240 #15 0x00677698 in main (argc=3, argv=0x2381f60) at main.c:196 Some additional condition may be needed in the Assert() statement? // Antonin Houska (Tony) -- Sent via

Re: [HACKERS] Reference to parent query from ANY sublink

(luckily) found a new opportunity for the existing infrastructure. To change the infrastructure because of this small feature would be exactly the opposite. Thanks for having taken a look at it. // Antonin Houska (Tony) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Reference to parent query from ANY sublink

to achieve such conditions without this patch. Thanks for your comments. // Antonin Houska (Tony) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Backup throttling

Thanks for checking. The new version addresses your findings. // Antonin Houska (Tony) On 12/09/2013 03:49 PM, Fujii Masao wrote: On Fri, Dec 6, 2013 at 6:43 PM, Boszormenyi Zoltan z...@cybertec.at wrote: Hi, 2013-12-05 15:36 keltezéssel, Antonin Houska írta: On 12/02/2013 02:23 PM

Re: [HACKERS] Reference to parent query from ANY sublink

On 12/06/2013 03:33 PM, Kevin Grittner wrote: Antonin Houska antonin.hou...@gmail.com wrote: SELECT * FROMtab1 a LEFT JOIN tab2 b ON a.i = ANY ( SELECT k FROMtab3 c WHEREk = a.i); This query works with k in any or all tables

Re: Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

Tested git apply and build again. No warnings. The regression test also looks good to me now. I'm done with this review. (Not sure if I should move it to 'ready for committer' status or the CFM should do). // Antonin Houska (Tony) On 12/06/2013 02:01 PM, Boszormenyi Zoltan wrote: 2013-12-04

Re: [HACKERS] Backup throttling

On 12/02/2013 02:23 PM, Boszormenyi Zoltan wrote: Hi, I am reviewing your patch. Thanks. New version attached. * Does it follow the project coding guidelines? Yes. A nitpicking: this else branch below might need brackets because there is also a comment in that branch: +

Re: [HACKERS] Reference to parent query from ANY sublink

On 10/31/2013 09:37 PM, Antonin Houska wrote: On 10/31/2013 03:46 PM, Antonin Houska wrote: I'm not sure if it's legal for the WHERE clause to reference LHS of the original outer join (a.j). Some more restriction may be needed. I need to think about it a bit more. For a subquery or sublink

Review: [HACKERS] ECPG infrastructure changes part 1, was: Re: ECPG fixes

how this is usually enforced. I'm mentioning it for the sake of completeness. // Antonin Houska (Tony) On 11/28/2013 03:21 PM, Boszormenyi Zoltan wrote: 2013-11-20 14:53 keltezéssel, Boszormenyi Zoltan írta: 2013-11-20 14:41 keltezéssel, Boszormenyi Zoltan írta: 2013-11-12 07:15 keltezéssel

Re: [HACKERS] Todo item: Support amgettuple() in GIN

of the key array. // Antonin Houska (Tony) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Todo item: Support amgettuple() in GIN

On 11/29/2013 01:57 PM, Andreas Karlsson wrote: On 11/29/2013 09:54 AM, Antonin Houska wrote: On 11/29/2013 01:13 AM, Andreas Karlsson wrote: When doing partial matching the code need to be able to return the union of all TIDs in all the matching posting trees in TID order (to be able to do

Re: [HACKERS] Easily reading debug_print_plan

On 11/20/2013 09:12 AM, Craig Ringer wrote: Hi all I'm spending a lot of time staring at parse and plan trees at the moment, and I'm finding reading them rather cumbersome. For those of you who do this a lot, do you use any sort of tooling to help you out? vim editor. The '%' shortcut

[HACKERS] Review: HStore Gin Speedup

that creates 2 indexes on the hstore column - one using the existing GIN (default) opclass and one using the new one (combined). The execution plan will then show if an index is used and if it's the correct one. // Antonin Houska (Tony) -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Information about Access methods

On 11/13/2013 08:59 AM, Rohit Goyal wrote: Could you please suggest something about abt update operation of B tree index. access/nbtree/README is probably the next text to read. It points to theoretical background and also explains specifics of Postgres implementation. // Antonin Houska (Tony

Re: [HACKERS] Comment - uniqueness of relfilenode

On 11/10/2013 12:57 AM, Robert Haas wrote: On Thu, Nov 7, 2013 at 10:56 AM, Antonin Houska antonin.hou...@gmail.com wrote: catalog/catalog.c:GetNewRelFileNode() and its calls indicate that the following change makes sense: diff --git a/src/include/storage/relfilenode.h b/src/include

[HACKERS] Comment - uniqueness of relfilenode

a particular database. + * Notice that relNode is only unique within a particular tablespace. * * Note: spcNode must be GLOBALTABLESPACE_OID if and only if dbNode is * zero. We support shared relations only in the global tablespace. // Antonin Houska (Tony) -- Sent via pgsql-hackers mailing

[HACKERS] Reference to parent query from ANY sublink

and into the nullable side of OUTER JOIN respectively, each before the patch is applied and after that. So far I didn't test recursive processing, but don't expect problems here. Can the change be as simple as this or do I neglect anything? // Antonin Houska (Tony) diff --git a/src/backend/optimizer/plan

Re: [HACKERS] Reference to parent query from ANY sublink

On 10/31/2013 03:46 PM, Antonin Houska wrote: Can the change be as simple as this or do I neglect anything? Well, the example of outer join is wrong. Instead I think query SELECT * FROMtab1 a LEFT JOIN tab1 b ON b.i = ANY ( SELECT tab2.k

  1   2   >