Re: [HACKERS] WIP: Aggregation push-down

Antonin Houska 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 aggregation of the j

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

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. -- Antonin Houska Cybertec Schönig &a

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

Magnus Hagander wrote: > > On Fri, Aug 25, 2017 at 12:12 AM, Antonin Houska wrote: > > I like this idea in general. > > Then it's supposed to change some of its attributes > > > adjust_log_stream_attr(&stream->filename, "my_extension.log")

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

Tomas Vondra wrote: > On 08/28/2017 11:23 AM, Antonin Houska wrote: > > Craig Ringer wrote: > > > >> On 25 August 2017 at 15:12, Antonin Houska wrote: > >> > >> How will this play with syslog? csvlog? etc? > > > > There's

Re: [HACKERS] WIP: Aggregation push-down

Ashutosh Bapat wrote: > On Thu, Aug 17, 2017 at 8:52 PM, Antonin Houska wrote: > > Antonin Houska wrote: > > > >> Antonin Houska wrote: > >> > >> > This is a new version of the patch I presented in [1]. > >&

Re: [HACKERS] WIP: Aggregation push-down

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 wrote: > > Antonin Houska wrote: > > > Antonin Houska wrote: >

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

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.postgresql-support.de, http://www

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

Ashutosh Bapat wrote: > On Fri, Sep 1, 2017 at 6:05 PM, Antonin Houska wrote: > > > > > > > > * get_partitioned_child_rels_for_join() > > > > I think the Assert() statement is easier to understand inside the loop, see > > the assert.diff attachme

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

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. -- Antonin Houska Cybertec Schönig & Schönig Gmb

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

nk 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/backend/optimiz

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

Masahiko Sawada wrote: > On Fri, Aug 25, 2017 at 4:12 PM, Antonin Houska wrote: > > Attached is a draft patch to allow extension to write log messages to a > > separate file. > > Does it allow postgres core code to write log messages to multiple log > files as well?

[HACKERS] Write operations in parallel mode

STATE), 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

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

Craig Ringer wrote: > On 25 August 2017 at 15:12, Antonin Houska wrote: > > How will this play with syslog? csvlog? etc? There's nothing special about csvlog: the LogStream structure has a "destination" field, so if particular extension wants this kind of ou

[HACKERS] WIP: Separate log file for extension

enhancement, but it might be useful for many other extensions. -- 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/postmaster/postmaster.c b/src/backend/postmaster/postmaste

Re: [HACKERS] WIP: Aggregation push-down

Antonin Houska wrote: > Antonin Houska wrote: > > > This is a new version of the patch I presented in [1]. > > Rebased. > > cat .git/refs/heads/master > b9a3ef55b253d885081c2d0e9dc45802cab71c7b This is another version of the patch. Besides other changes, it e

[HACKERS] Unused field of ProjectionPath

lan = subplan; 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

Re: [HACKERS] asynchronous execution

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

Re: [HACKERS] asynchronous execution

c wouldn't be necessary. ExecAsyncRequest would use the set to look for space for new requests by iterating it and trying to find the first gap (which corresponds to completed request). And finally, item would be removed from the set at the moment the request state is being set to ASYNCREQ_C

Re: [HACKERS] asynchronous execution

or 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://www.cybertec.at OPT_HOST=&quo

Re: [HACKERS] snapbuild woes

OldestSafeDecodingTransactionId(!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, http

Re: [HACKERS] Partition-wise aggregation/grouping

Jeevan Chalke wrote: > On Thu, Apr 27, 2017 at 4:53 PM, Antonin Houska wrote: > > > Robert Haas wrote: > > > Well, I'm confused. I see that there's a relationship between what > > > Antonin is trying to do and what Jeevan is trying to do, but I can'

Re: [HACKERS] Partition-wise aggregation/grouping

Antonin Houska wrote: > > Jeevan Chalke wrote: > > > Our work will overlap when we are pushing down the aggregate on partitioned > > base relation to its children/partitions. > > > > I think you should continue working on pushing down aggregate onto th

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 wrote: > On Tue, Mar 21, 2017 at 1:47 PM, Antonin Houska wrote: > > Jeevan Chalke wrote: > > IIUC, it seems that you are trying to push down the a

Re: [HACKERS] Partition-wise aggregation/grouping

ans 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 & Schönig

Re: [HACKERS] Parameterization of partial path

Robert Haas wrote: > On Thu, Feb 9, 2017 at 12:36 PM, Antonin Houska wrote: > > When looking at try_partial_hashjoin_path and try_partial_nestloop_path > > functions I'm failing to understand the comment "Parameterized partial paths > > are not supported.&

[HACKERS] Parameterization of partial path

return; Shouldn'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,

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

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 Hou

Re: [HACKERS] asynchronous execution

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.postgresql-support.de, http:/

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

lation 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%2BbdrMK2Nf3EfGWaJu2WbzQUYcSBUi02a

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

*/ * relation.h:1831 boolinner_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.de, http://www.cybertec.at

Re: [HACKERS] PoC: Grouped base relation

David Rowley wrote: > On 20 January 2017 at 00:22, Antonin Houska 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 other becomes > > unique due to aggregation (and if

Re: [HACKERS] PoC: Grouped base relation

ns. But 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. > > Otherwise > >

Re: [HACKERS] PoC: Grouped base relation

Antonin Houska 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 planner limitation to estimate

Re: [HACKERS] PoC: Grouped base relation

Tomas Vondra wrote: > On 01/17/2017 08:05 PM, Antonin Houska wrote: > > Tomas Vondra wrote: > > > > > >> Another thing is that in my experience most queries do joins on foreign > >> keys > >> (so the PK side is unique by definition), so the be

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 wrote: > On 01/17/2017 12:42 AM, David Rowley wrote: > > On 10 January 2017 at 06:56, Antonin Houska wrote: > > I've been thinking about

Re: [HACKERS] PoC: Grouped base relation

where 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 Wien

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

Antonin Houska 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 wrote: >> I wonder if the else if (sleep > 0) at the bottom of throttle() should just >> be a simple else

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

ver 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

e cluster nor the core dump, 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

[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 wrote: > On Tue, Aug 23, 2016 at 10:10 AM, Antonin Houska 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 subtle difference. Thanks for answer. -- Ant

[HACKERS] Question about MVCC-unsafe commands

heap 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, htt

[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

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: http://www.postgres

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

fundamental 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 mai

[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 wrote: > On Thu, Aug 6, 2015 at 1:24 PM, Robert Haas wrote: > > On Thu, Aug 6, 2015 at 9:04 AM, Antonin Houska wrote: > >> Can anyone please explain why the following patch shouldn't be applied? > >> > >> diff --git a/src/backend/storage/ipc

Re: [HACKERS] Race conditions in shm_mq.c

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

[HACKERS] Race conditions in shm_mq.c

(receiver's) WaitLatch(). So sender 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

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

I'm failing to understand why 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

Re: [HACKERS] Parallel Seq Scan

omment. 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@postgresq

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

er too. -- 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/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c index 474137a..e6ebd9d 100644 --- a/src/back

[HACKERS] Concurrent calls of _hash_getnewbuf()

separate ("regular") lock 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://ww

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

Antonin Houska 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

age-id/ca+tgmoy4x7vkyc4dawujutuboyxe2qsjf9aybhwzjxxwoc6...@mail.gmail.co -- 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/h

Re: [HACKERS] Corner case for add_path_precheck

Tom Lane wrote: > Antonin Houska 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 add_path_precheck(

[HACKERS] Corner case for add_path_precheck

the costs exactly, 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@postgre

Re: [HACKERS] memory explosion on planning complex query

tting from_collapse_limit / join_collapse_limit to lower-than-default value ? -- 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@postgresq

[HACKERS] pg_class(relpersistence) of hash index

elpersistence from pg_class where relname='a_i_idx'; 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 mai

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() ? -

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

; for functions used in index 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 Cybe

Re: [HACKERS] Unintended restart after recovery error

y. I'd need to think more if the end of crash recovery can be safely identified during the replay and signaled 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 pgs

Re: [HACKERS] array exclusion constraints

hjwp0vtp5fgzle6evsw...@mail.gmail.com Regarding implementation, more recent thread summarizes 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.postgre

Re: [HACKERS] Unintended restart after recovery error

Fujii Masao wrote: > On Wed, Nov 12, 2014 at 6:52 PM, Antonin Houska wrote: > > While looking at postmaster.c:reaper(), one problematic case occurred to me. > > > > > > 1. Startup process signals PMSIGNAL_RECOVERY_STARTED. > > > > 2. Checkpointer

Re: [HACKERS] Unintended restart after recovery error

Antonin Houska 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 Han

[HACKERS] Unintended restart after recovery error

_("startup process")); 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 (p

Re: [HACKERS] Convert query plan to sql query

mariem 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 Cybertec

Re: [HACKERS] from_collapse_limit considerations

[ I think I responded earlier but don't see my mail in the archive... ] Tom Lane wrote: > Antonin Houska writes: > > I noticed that - unlike join_collapse_limit - the from_collapse_limit does > > not > > enforce maximum length of the top-level list. Shouldn't

[HACKERS] from_collapse_limit considerations

; + else +fromlist_new = lappend(fromlist_new, fromlist_sub); + } + + /* Free 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 Specia

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 >> ---

[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 d

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 co

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 " makes use > of the returned value. ok >> >>

[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 s

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

> express queries like 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-hacke

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 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 Hou

Re: [HACKERS] Equivalence Rules

k if new joins (those not present 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 rul

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

ge to finish without postmaster, however it's executed under walsender process. Question is where !PostmasterIsAlive() check should be added. I think it should go to the main loop of perform_base_backup(), but that's probably not in the scope of this patch. Do you think that my patch should

[HACKERS] bgworker crashed or not?

;s no success). Do we need my patch, my patch + 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/postmaster/postmas

Re: [HACKERS] Backup throttling

n 01/20/2014 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

Re: [HACKERS] Backup throttling

rge divisor value in the first place? > I propose we set that constant to a smaller value such as 8. I tried to use THROTTLING_SAMPLE_MIN and THROTTLING_MAX_FREQUENCY to control both the minimum and maximum chunk size. It was probably too generic, THROTTLING_SAMPLE_MIN is no longer there. New pat

[HACKERS] Assertion failure in base backup code path

.c:4085 #12 0x0071742e in BackendStartup (port=0x23a2e90) at postmaster.c:3774 #13 0x00713cc9 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 S

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

fit strangely-written queries. Originally it seemed to me that I just (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)

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

pect > it's too simple somehow, but it's also possible that it's OK and the > real issue is some previously undetected bug in LATERAL processing. So far I have no idea how 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] Reference to parent query from ANY sublink

On 12/06/2013 03:33 PM, Kevin Grittner wrote: > Antonin Houska wrote: > >> SELECT * >> FROMtab1 a >> LEFT JOIN >> tab2 b >> ON a.i = ANY ( >> SELECT k >> FROMtab3 c >> WHEREk = a.i); >

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 wrote: >> Hi, >> >> 2013-12-05 15:36 keltezéssel, Antonin Houska írta: >>

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 wrot

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 mo

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: > > +

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

e preprocessed & compiled against the PG 9.4. I don't know 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: >>

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

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

ch more than the number of elements 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] 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 '%' short

[HACKERS] Review: HStore Gin Speedup

test 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

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

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 > wrote: >> catalog/catalog.c:GetNewRelFileNode() and its calls indicate that the >> following change makes sense: >> >> >> diff --git a/src/include/storage/re

[HACKERS] Comment - uniqueness of relfilenode

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-hacke

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 tab

[HACKERS] Reference to parent query from ANY sublink

o 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

  1   2   >