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
ut 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...@postgrespro.ru
--
Sent via pg
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 cou
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
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
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 mailto:i.mu...@postgrespro.ru>> wrote:
lad to hear it.
[1]
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 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 relcache?
You might be abl
h object is built 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:
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 b
omments to match project code style, 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 Mu
good plan for "query 2").
Vladimir
Thanks, I get it now. The 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. Appare
debugged the last two queries to figure out the difference between
them. It turned out that that the query 2) transforms to the same as
query 1). And in 3rd query 'OFFSET' statement prevents rewriter from
transforming the query, so it is 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
teful if you take a look at the patch 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/ind
The
attached patch 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/ba
27;1', 'SELECT 1 returns 1');
or else:
my ($ret, $stdout, $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...@
t pl_exec.c:1336
#12 0x00007f108cc5c35d in plpgsql_exec_function (func=0x1cc2a90,
fcinfo=0x1cf7f50, simple_eval_estate=0x0) at pl_exec.c:434
...
Thanks
--
Ildar Musin
i.mu...@postgrespro.ru
er than constraint exclusion. But still there is a
noticeable performance degradation from copying PartitionDesc 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 sugg
/DELETE query?
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
26e5cd8, rte=0x268ebf0) at plancat.c:1302
#13 0x00000072a18d 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
ctually
contains inserted row) and 'test_3' and return nothing:
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 &l
e any metadata - only row data in network byte order are exported"
Did you mean "only raw data in network byte order is exported"?
And there are two entries for this patch on commitfest page: in
"miscellaneous" and "sql" sections. Probably it's better to re
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 menti
24 matches
Mail list logo
