for parellel nodes. Now, I'm working at this feature.
That's all. CC welcome!
--
Maksim Milyutin
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
diff --git a/src/backend/storage/ipc/procsignal.c b/src/backend/storage/ipc/procsignal.c
index a3d6ac5..07270a9 1
000/* calls=1
Execution time: 340.766 ms
(5 rows)
My patch fixes this problem.
--
Maksim Milyutin
Postgres Professional:http://www.postgrespro.com
Russian Postgres Company
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index dbd27e5..808e23e 100644
--- a/src/bac
On Mon, Aug 29, 2016 at 5:22 PM, maksim mailto:m.milyu...@postgrespro.ru>> wrote:
Hi, hackers!
Now I complete extension that provides facility to see the current
state of query execution working on external session in form of
EXPLAIN ANALYZE output. This extension works
Hi,
On 2016-08-29 18:22:56 +0300, maksim wrote:
Now I complete extension that provides facility to see the current state of
query execution working on external session in form of EXPLAIN ANALYZE
output. This extension works on 9.5 version, for 9.6 and later it doesn't
support det
On 2016-08-30 11:22:43 +0300, Maksim Milyutin wrote:
Hi,
On 2016-08-29 18:22:56 +0300, maksim wrote:
Now I complete extension that provides facility to see the current state of
query execution working on external session in form of EXPLAIN ANALYZE
output. This extension works on 9.5 version
On Tue, Aug 30, 2016 at 9:34 AM, Maksim Milyutin
mailto:m.milyu...@postgrespro.ru>> wrote:
On Mon, Aug 29, 2016 at 5:22 PM, maksim
mailto:m.milyu...@postgrespro.ru>
<mailto:m.milyu...@postgrespro.ru
<mailto:m.milyu...@postgrespro.ru>>>
01.09.2016 18:58, Tom Lane пишет:
Maksim Milyutin writes:
On Tue, Aug 30, 2016 at 9:34 AM, Maksim Milyutin
mailto:m.milyu...@postgrespro.ru>> wrote:
Yes, but the problem is that nothing gives you the guarantee that at the
moment you decide to handle the interrupt, the QueryDesc stru
ssion from composite type.
On November commitfest I'll lay out patch that covers your case.
--
Regards,
Maksim Milyutin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
esql.org/message-id/CAM-w4HOVftuv5RVi3a%2BsRV6nBpg204w7%3DL8MwPXVvYBFo1uM1Q%40mail.gmail.com
--
Regards,
Maksim Milyutin
x27;CREATE INDEX
paritioned_table' statement as a cascade operation.
As a result, we can specify name for each concrete index while
recreating a whole hierarchy.
--
Regards,
Maksim Milyutin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o implement this
feature?
Maybe in this thread[1] your described problem are solved through
introducing Parallel Append node?
1.
https://www.postgresql.org/message-id/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1%2BS%2BvRuUQ%40mail.gmail.com
--
Regards,
Maksim Milyutin
--
Sent via pg
sage-id/CA+TgmoZUwj=qynak+f7xef4w_e2g3xxdmnsnzmzjuinhrco...@mail.gmail.com
2.
https://www.postgresql.org/message-id/2b0d42f2-3a53-763b-c9c2-47139e4b1c2e%40lab.ntt.co.jp
--
Maksim Milyutin
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hacker
ulation, though. But IMO it's
not flexible case.
It would be a good thing if a regular table could be partitioned through
separate command. Then your idea would not be restrictive.
--
Maksim Milyutin
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Se
iqueness is guaranteed through global index on partitioned table apart
from the case when the index key are the same as partitioning key (or
index comprises partitioning key in general).
Thanks for your comment. I'll try to propose the first patches as soon
as possible.
--
Maksim M
s lack
is caught through if-statement [1] I think it is not safe.
My patch fixes this issue.
1. src/backend/storage/smgr/md.c:1385
--
Maksim Milyutin
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
diff --git a/src/backend/catalog/heap.c b/src/backend/catalog/he
rel->rd_rel->relkind != RELKIND_FOREIGN_TABLE &&
+ rel->rd_rel->relkind != RELKIND_PARTITIONED_TABLE)
{
RelationDropStorage(rel);
}
--
Maksim Milyutin
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
On 01.03.2017 13:53, Maksim Milyutin wrote:
Hi hackers!
As I've understood from thread [1] the main issue of creating local
indexes for partitions is supporting REINDEX and DROP INDEX operations
on parent partitioned tables. Furthermore Robert Haas mentioned the
problem of creating index o
On 07.04.2017 13:05, Etsuro Fujita wrote:
On 2016/12/14 16:20, Etsuro Fujita wrote:
On 2016/12/09 19:46, Maksim Milyutin wrote:
I would like to work on two tasks:
- insert (and eventually update) tuple routing for foreign partition.
- the ability to create an index on the parent and have all
On 10.04.2017 13:46, Greg Stark wrote:
On 4 April 2017 at 17:10, Maksim Milyutin wrote:
3. As I noticed early pg_depend table is used for cascade deleting indexes
on partitioned table and its children. I also use pg_depend to determine
relationship between parent and child indexes when
On 10.04.2017 14:20, Robert Haas wrote:
On Tue, Apr 4, 2017 at 12:10 PM, Maksim Milyutin
wrote:
1. I have added a new relkind for local indexes named RELKIND_LOCAL_INDEX
(literal 'l').
Seems like it should maybe be RELKIND_PARTITIONED_INDEX. There's
nothing particularly "
On 18.04.2017 13:08, Amit Langote wrote:
Hi,
Hi, Amit!
On 2017/04/17 23:00, Maksim Milyutin wrote:
Ok, thanks for the note.
But I want to discuss the relevancy of introduction of a new relkind for
partitioned index. I could to change the control flow in partitioned index
creation
robust PROGRESS command.
1. https://github.com/postgrespro/pg_query_state
2.
https://www.postgresql.org/message-id/dbfb1a42-ee58-88fd-8d77-550498f52bc5%40postgrespro.ru
3. https://www.postgresql.org/message-id/24182.1472745492%40sss.pgh.pa.us
--
Maksim Milyutin
Postgres Professional: ht
On 18.04.2017 17:39, Remi Colinet wrote:
Hello Maksim,
The core implementation I suggested for the new PROGRESS command uses
different functions from the one used by EXPLAIN for its core
implementation.
Some source code is shared with EXPLAIN command. But this shared code is
only related to
On 19.04.2017 11:42, Ashutosh Bapat wrote:
On Tue, Apr 18, 2017 at 4:43 PM, Maksim Milyutin
wrote:
Local partitioned indexes can be recognized through the check on the relkind
of table to which the index refers. Something like this:
heap = relation_open(IndexGetRelation(indexid, false
On 19.04.2017 17:13, Remi Colinet wrote:
Maksim,
2017-04-18 20:31 GMT+02:00 Maksim Milyutin mailto:m.milyu...@postgrespro.ru>>:
On 18.04.2017 17:39, Remi Colinet wrote:
Regarding the queryDesc state of SQL query upon receiving a
request to
report its exe
10.08.17 23:01, Robert Haas wrote:
On Wed, Apr 19, 2017 at 5:25 AM, Maksim Milyutin
wrote:
Ok, thanks for the feedback. Then I'll use a new relkind for local
partitioned index in further development.
Any update on this?
I'll continue to work soon. Sorry for so long delay.
my
patch works
only with explain (and segfault without).
Instrumentation is initialized only with analyze (log_analyze is true)[1]
Is there a simple way to get ntuples?
It's interesting question. In one's time I didn't find any way to get
the amount of tuples emitted from a node.
1. contrib/auto_explain/auto_explain.c:221
--
Regards,
Maksim Milyutin
nd is not invalidated at each function call. This is because** the
statement of this query doesn't have any dependency from the 'tbl'
relation (/relationOids/ list of /CachedPlanSource/ struct).
Attached patch resolves this problem by adding dependency from relation
upon detection
On 19.09.2017 11:09, Daniel Gustafsson wrote:
Removing reviewer Maksim Milyutin from patch entry due to inactivity and
community account email bouncing. Maksim: if you are indeed reviewing this
patch, then please update the community account and re-add to the patch entry.
cheers ./daniel
25.09.17 20:50, Maksim Milyutin wrote:
I have found out the problem when try to sequentially call the
function that casts constant to composite type of temporary table that
is deleted ateach transaction termination (i.e. at each function call
completion).
For example, we have the following
erbose one for
partition tables regardless of the type of partition.
Attached small patch removes any output about partition constraint in
non-verbose mode.
--
Regards,
Maksim Milyutin
diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c
index d22ec68..b301219 100644
--- a/src/bin/psq
On 28.09.2017 16:29, Jesper Pedersen wrote:
On 09/28/2017 09:19 AM, Maksim Milyutin wrote:
E.g. "No partition constraint" vs. "Partition constraint:
satisfies_hash_partition(...)".
I also noticed ambiguity in printing "No partition constraint" in
non-verbose
be missing something.
Anyhow, we have to protect ourselves from empty output from
*pg_get_partition_constraintdef*. And printing *No partition constraint*
would be good point to start to examine why we didn't get any constraint
definition.
--
Regards,
Maksim Milyutin
er. Namely conflict in src/backend/executor/execMain.c
--
Regards,
Maksim Milyutin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 26.09.2017 23:25, Maksim Milyutin wrote:
25.09.17 20:50, Maksim Milyutin wrote:
I have found out the problem when try to sequentially call the
function that casts constant to composite type of temporary table
that is deleted ateach transaction termination (i.e. at each function
call
'pair' type I'll get the following message:
ERROR: cached plan must not change result type
I don't know whether it's right behavior. Anyhow your point is a good
motivation to experiment and investigate different scenarios of work
with cached plan that depends on non-stable type. Thanks for that.
--
Regards,
Maksim Milyutin
n dirty hacks, so the FDW API has to be improved. As for the
extended index support, it doesn't look like a super-hard task.
--
Maksim Milyutin
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
Hi,
could somebody explain me please why following select
SELECT docid FROM prod.guids
GROUP BY docid HAVING( COUNT(docid) > 1 )
taking 15 min on 2 Proc Box on 1M rows, where number of duplicates
around 300K,
and docid indexed and not null and char(16).
May be I am doing something wrong?
Hi,
I have some SQL function, just regular function selects data by using 4
joins nothing fancy,
but one thing pretty noticeable,
I have to display 3 different columns with same date formatted
differently,
here are 3 different snippets:
1. SELECT t.x,t.y,TO_CHAR(t.dt, 'DD/MM/')
FROM
function call, would be much helpful in such case.
In comparison with Microsoft SQL, productivity of using
profiling/debugging tools sorry to say that, far behind.
-Original Message-
From: Karel Zak [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 24, 2003 1:04 AM
To: Maksim Likharev
Cc
Hi,
I have interesting question that stops me now.
Suppose I have 2 functions
1. preparestate
2. doajob
first allocates some state using
MemoryContextAlloc(TopTransactionContext)
or something, another function using that memory.
question is how I lookup that memory in second function doajob?
()
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 10:14 PM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]
Subject: Re: [GENERAL] PG crash on simple query, story continues
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> SELECT p.docid FR
mlen + 1);
}
pfree(val);
val = xfrmstr;
}
-Original Message-
From: Maksim Likharev
Sent: Tuesday, July 08, 2003 9:35 AM
To: 'Tom Lane'
Cc: [EMAIL PROTECTED]; '[EMAIL PROTECTED]'
Subject: RE: [GENERAL] PG crash on simple query, story continues
m on SunOS 5.8,
BTW on Linux it works
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 11:45 AM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [GENERAL] PG crash on simple query, story continues
"Maksim Likharev
I would referrer dump that gar.xxg, and put PG on Linux,
but this is not up to me.
Thanks for the help.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 3:58 PM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [GENERAL] PG
, NO WARRANTY, NO NOTHING, just for you information.
Regards.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 3:58 PM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [GENERAL] PG crash on simple query, story continues
&qu
Possible, but if before almost every tenth query crash the server
now it stays, that's only I care about.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 12, 2003 2:05 PM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [HA
Just want to add my $0.03 on that.
single file DB has some benefits as:
1. ability to allocate one continues chunk on disk,
significantly reduces disk seeks,
mostly ancestral but still true today ( I still see DB living on none
arrays )
2. And of cause countless design considerations.
Say
Hi,
Using PG under Cygwin we having following error message during INSERT
INTO
"FreeSpaceMap hashtable out of memory".
What does that mean?
And if for a moment step out of knowledge 'PG under Cygwin', what in
general
this message is about and more important how to fix it?
Thank you.
---
PROTECTED]
Sent: Wednesday, October 01, 2003 2:51 PM
To: Maksim Likharev
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] FreeSpaceMap hashtable out of memory
"Maksim Likharev" <[EMAIL PROTECTED]> writes:
> Using PG under Cygwin we having following error message during INSERT
>
50 matches
Mail list logo