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
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
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
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
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
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
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
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
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
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
>> ---
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
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
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
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
= 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"
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
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
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'
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
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
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
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
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?
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
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
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
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
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:
>
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].
> >&
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
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")
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
(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
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.
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
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,
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
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
;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
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
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
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
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
lsewhere in the thread, the client-side
throttling was chosen because it seemed to be less invasive. But the
discussion (including this your comment) keeps me no longer convinced
that it's the best way. I'll reconsider things.
// Antonin Houska (Tony)
--
Sent via pgsql-hackers mail
On 08/26/2013 02:33 PM, Craig Ringer wrote:
> On 08/26/2013 08:15 PM, Hannu Krosing wrote:
>> On 08/26/2013 12:50 PM, Antonin Houska wrote:
>>>> On 08/22/2013 03:33 PM, Craig Ringer wrote:
>>>>>> On 08/22/2013 01:39 PM, PostgreSQL - Hans-Jürgen Schönig
o implement it for the next version of the patch. However the
pg_basebackup is different from VACUUM, CLUSTER, etc. in that it
retrieves the data directly from file system, as opposed to buffers. So
there seems to be little room here for utilization of (future)
'throttling infrastructure'
On 07/24/2013 09:20 AM, Antonin Houska wrote:
> Hello,
> the purpose of this patch is to limit impact of pg_backup on running
> server.
Attached is a new version. Server-side implementation this time.
Antonin Houska (Tony)
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src
On 09/03/2013 06:56 PM, Alvaro Herrera wrote:
>> +/*
>> + * Only the following suffixes are allowed. It's not
>> too useful to
>> + * restrict the rate to gigabytes: such a rate will
>> probably bring
>> + * signific
While reading storage/lmgr/lock.c I noticed that the last (proc)
argument of LockCheckConflicts() is not referenced inside the function.
Is it just a remnant from older version?
// Antonin Houska (Tony)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
seems grotty and completely unlike the way we do things elsewhere
> (compare GIN indexes which have rbtrees inside them).
Perhaps you meant that GIN has B-tree inside. RBTree is in fact used by
GiST, but only as in-memory structure during the search - to get the
tuples sorted by distance.
//
As for this
http://www.postgresql.org/message-id/20130903125155.ga18...@awork2.anarazel.de
there eventually seems to be a consensus (I notice now the discussion
was off-list):
> On 2013-09-03 23:21:57 +0200, Antonin Houska wrote:
>> On 09/03/2013 02:51 PM, Andres Freund wrote:
>>
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
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
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
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
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
Hello,
in the related discussions mentioned on TODO list
http://archives.postgresql.org/pgsql-hackers/2009-09/msg00292.php
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00991.php
(The 1st is rather on SQL, I didn't focuss on it yet.)
the implementation is discussed from optimizer/execu
On 03/10/2012 02:15 AM, Tom Lane wrote:
Um ... how do you get the subquery result rows to join to only the
correct rows of the other tables?
The subquery just restricts the set of rows that the function has to
evaluate. The main query is supposed to perform the join.
I understand, such a join ca
problem itself or anything
else. You'll probably know better.
(4f14c86d7434376b95477aeeb07fcc7272f4c47d is the last commit in my
environment)
Regards,
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
ubquery has gone
at earlier stage of the planning.
Regards,
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
expects aligned pointer.
* gindatapage.c:ginCheckPlaceToDataPageLeaf() - comment "if leaf data
page" should probably be "on a leaf data page" or so.
Regards,
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
On 06/29/2013 11:00 AM, Heikki Linnakangas wrote:
On 27.06.2013 17:20, Antonin Houska wrote:
I was curious about the new layout of the data page, so I spent a while
looking into the code.
It's interesting, but I suspect 2 things are not o.k.:
* gindatapage.c:dataIsEnoughSpace() - 'i
The lower limit could also be used in initsplan.c:check_outerjoin_delay().
Is this worth a patch? It's not much coding but I'd appreciate some
feedback before I try to do anything.
Thanks,
Antonin Houska (Tony)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
(non-LATERAL) queries or rather
patterns where the ph_may_need optimization clearly appears to be
important sounds to me like a good SQL exercise, but I'm afraid I won't
have time for it in the next few days.
//Antonin Houska (Tony)
--
Sent via pgsql-hackers mailing list
On 07/10/2013 07:28 AM, Atri Sharma wrote:
I am not sure if the part you mentioned is inline with the case I am
talking about.
Can you please post an example of such a join removal? I mean a query
before and after the removal. Thanks,
//Tony
--
Sent via pgsql-hackers mailing list (pgsql-hac
On 07/04/2013 06:11 PM, Antonin Houska wrote:
On 07/03/2013 08:32 PM, Tom Lane wrote:
Another possibility would be to keep the optimization, but disable it in
queries that use LATERAL. I don't much care for that though --- seems
too Rube Goldbergish, and in any case I have a lot less fai
Hello,
the purpose of this patch is to limit impact of pg_backup on running
server. Feedback is appreciated.
// Antonin Houska (Tony)
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index eb0c1d6..3b7ecfd 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
On 07/31/2013 07:13 AM, Gibheer wrote:
Hi,
That is a really nice feature.
I don't pretend it's my idea, I just coded it. My boss proposed the
feature as such :-)
I took a first look at your patch and some empty lines you added (e.g. line 60
your patch). Can you remove
them?
Sure, will do in
to check if the diff is correct)
// 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
pe as opposed to that of the pseudotype.
Is there any misconception in this patch proposal?
// Antonin Houska (Tony)
diff --git a/src/backend/access/gin/ginget.c b/src/backend/access/gin/ginget.c
index cb17d38..9e1c665 100644
--- a/src/backend/access/gin/ginget.c
+++ b/src/backend/access/gin/ginge
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
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
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
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
;
+ 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
[ 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
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
_("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
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
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
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
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
; 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
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() ?
-
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
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
By chance (?) I got similar one today too, when dropping extension:
ERROR: could not open file "base/12623/12548": No such file or directory
I thought something might have gone wrong during Linux upgrade 2 days
ago, but it's not likely that we both have the issue.
I wonder if something is br
I'm also implementing an extension where direct access to non-fixed OIDs
(i.e. no catalog cache lookup by name) would be very helpful. I spent some
time thinking about a workaround that makes OID registry unnecessary.
How about the following?
1. Add a new varlena column to pg_proc catalog table,
Hello,
following this short discussion
http://archives.postgresql.org/message-id/4f5aa202.9020...@gmail.com
I gave it one more try and hacked the optimizer so that function can
become an inner relation in NL join, parametrized with values from the
outer relation.
I tried to explain my thoughts
On 05/22/2012 09:31 PM, Robert Haas wrote:
This implementation looks different than I'd expect: I would have
thought that it would work by generating paths with param_info set to
the appropriate set of rels to provide the necessary values, rather
than inventing its own mechanism for forcing a n
On 05/24/2012 12:46 AM, Tom Lane wrote:
Well, it's not per spec: what you did accepts queries that are invalid
per spec and are very likely to be errors rather than intentional
invocations of the LATERAL facility. This might be all right for
I think I saw queries where function is joined with
I found out by chance that \copyright command still contains 2011.
Perhaps documentation of "new year's day changes" needs to be updated,
if such exists.
Tony H.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
On 07/06/2012 02:13 AM, Bruce Momjian wrote:
On Thu, Jul 05, 2012 at 10:10:08PM +0200, Antonin Houska wrote:
I found out by chance that \copyright command still contains 2011.
Perhaps documentation of "new year's day changes" needs to be
updated, if such exists.
What version
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
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
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
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
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
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:
>>
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:
>
> +
1 - 100 of 129 matches
Mail list logo
