that original code
was reformatted and this led to merging conflicts. I've fixed that and
also introduced some minor improvements. The new version is in attachment.
Thanks!
--
Ildar Musin
i.mu...@postgrespro.ru
diff --git a/src/backend/utils/adt/ri_triggers.c b/src/backend/utils/adt/ri_triggers.c
index
ve discussed it earlier but it worth mentioning here too. You have
pd_prune_xid of type TransactionId which is treated elsewhere as
ShortTransactionId (see HeapPageGetPruneXid() and HeapPageSetPruneXid())
and hence introduces redundant 4 bytes. Could you please fix it?
--
Ildar Musin
i.mu...@po
Hi,
On 24.08.2017 22:44, Andres Freund wrote:
Hi,
On 2017-08-18 12:12:58 +0300, Ildar Musin wrote:
While we've been developing pg_pathman extension one of the most frequent
questions we got from our users was about global index support. We cannot
provide it within an extension. And I couldn't
18/08/2017 17:40, Alvaro Herrera пишет:
> Ildar Musin wrote:
>
>> While we've been developing pg_pathman extension one of the most frequent
>> questions we got from our users was about global index support. We cannot
>> provide it within an extension. And I couldn't fi
18/08/2017 17:45, Alvaro Herrera пишет:
> Erikjan Rijkers wrote:
>> On 2017-08-18 11:12, Ildar Musin wrote:
>>> Hi hackers,
>>>
>>> While we've been developing pg_pathman extension one of the most
>>> frequent questions we got from our users was abou
Hi Chris,
On 18.08.2017 16:15, Chris Travers wrote:
I would really like to see global indexes. It would make things a lot
easier for things like unique constraints across table inheritance trees.
On Fri, Aug 18, 2017 at 11:12 AM, Ildar Musin <i.mu...@postgrespro.ru
<mailt
]
https://www.postgresql.org/message-id/c8fe4f6b-ff46-aae0-89e3-e936a35f0cfd%40postgrespro.ru
Thanks!
--
Ildar Musin
i.mu...@postgrespro.ru
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi all,
I was looking through the RI triggers code recently and noticed a few
almost identical functions, e.g. ri_restrict_upd() and
ri_restrict_del(). The following patch is an attempt to reduce some of
repetitive code. Yet there is still room for improvement.
Thanks,
--
Ildar Musin
i.mu
Hi,
On 13.12.2016 21:10, Robert Haas wrote:
On Tue, Dec 13, 2016 at 12:22 PM, Ildar Musin <i.mu...@postgrespro.ru> wrote:
We've noticed that PartitionDispatch object is built on every INSERT query
and that it could create unnecessary overhead. Wouldn't it be better to keep
it in re
on every INSERT
query and that it could create unnecessary overhead. Wouldn't it be
better to keep it in relcache?
Thanks!
--
Ildar Musin
i.mu...@postgrespro.ru
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
Hi Vladimir,
On 05.09.2016 16:38, Ildar Musin wrote:
Hi Vladimir,
On 03.09.2016 19:31, Vladimir Sitnikov wrote:
Ildar>The reason why this doesn't work is that '~~' operator (which is a
Ildar>synonym for 'like') isn't supported by operator class for btree.
Since
Ildar>the only
, and moved
a few variables into the block where they are used. But the latter is
probably matter of personal taste, I guess.
regards
Thanks for that, I have some difficulties in expressing myself in
english, so it was very helpful.
Best regards,
--
Ildar Musin
i.mu...@postgrespro.ru
--
Sent via
e reason why it acts like this is that I used
match_clause_to_index() function to determine if IOS can be used with
the specified clauses. This function among other things checks if
operator matches the index opfamily. Apparently this isn't correct. I
wrote another prototype to test your case and i
s possible to use index only scan on
subquery and then filter the result of subquery with '~~' operator.
--
Ildar Musin
i.mu...@postgrespro.ru
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in
attachment. Any comments and tips are welcome.
Thanks!
--
Ildar Musin
i.mu...@postgrespro.ru
diff --git a/src/backend/optimizer/path/indxpath.c b/src/backend/optimizer/path/indxpath.c
index 2952bfb..9eb0e12 100644
--- a/src/backend/optimizer/path/indxpath.c
+++ b/src/backend/optimizer/path
removes it. Probably someone more advanced could edit the
function description to reflect changes?
Regards,
--
Ildar Musin
i.mu...@postgrespro.ru
diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index 76ade37..1eaa1cb 100644
--- a/src/backend/storage/buffer
stderr) =
$node->psql('postgres', 'SELECT 1');
is($stdout, '1', 'SELECT 1 returns 1');
The attached patch fixes this.
Regards,
Ildar Musin
--
Ildar Musin
i.mu...@postgrespro.ru
diff --git a/src/test/perl/README b/src/test/perl/README
index 9eae159..36d4120 100644
--- a/src/test/pe
c2a90,
fcinfo=0x1cf7f50, simple_eval_estate=0x0) at pl_exec.c:434
...
Thanks
--
Ildar Musin
i.mu...@postgrespro.ru
tionDesc structure:
with 2000 partitions RelationGetPartitionDesc() function spent more than
40% of all execution time on copying in first benchmark (measured with
`perf`). Using reference counting as Amit suggests will allow to
significantily decrease performance degradation.
Any comments and suggestions are v
ery?
Thanks!
--
Ildar Musin
i.mu...@postgrespro.ru
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
0x0072a18d in set_append_rel_size (root=0x268f1b8,
rel=0x26e5690, rti=1, rte=0x268ea80) at allpaths.c:947
...
--
Ildar Musin
i.mu...@postgrespro.ru
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ing:
select * from test where b < 100;
a | b
---+---
(0 rows)
explain (costs off) select * from test where b < 100;
QUERY PLAN
---
Append
-> Seq Scan on test
Filter: (b < 100)
-> Seq Scan on test_1
Filter: (b < 100)
(5
Probably it's better to remove one
of them to avoid confusion.
--
Ildar Musin
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
16/02/16 07:46, Amit Langote wrote:
Hi Josh,
On 2016/02/16 11:41, Josh berkus wrote:
On 02/15/2016 04:28 PM, Amit Langote wrote:
Also, you won't see any optimizer and executor changes. Queries will still
use the same plans as existing inheritance-based partitioned tables,
although as I
24 matches
Mail list logo
