Hi,
On 2019/05/29 14:01, Paul A Jungwirth wrote:
> On Sun, May 26, 2019 at 7:49 PM Michael Paquier wrote:
>> ... However you are adding a paragraph for something which is
>> completely unrelated to the issue we are trying to fix. If I were to
>> add something, I think that I would be more
On Sun, May 26, 2019 at 7:49 PM Michael Paquier wrote:
> Well, the point I would like to outline is that section 5.11.2 about
> declarative partitioning and 5.11.3 about partitioning with
> inheritance treat about two separate, independent partitioning
> methods. So removing the paragraph from
Kaigai-san,
On 2019/05/29 12:13, Kohei KaiGai wrote:
> One interesting data type in Apache Arrow is "Struct" data type. It is
> equivalent to composite
> type in PostgreSQL. The "Struct" type has sub-fields, and individual
> sub-fields have its own
> values array for each.
>
> It means we can
Hello,
A recent revision of PG-Strom has its columnar-storage using Apache
Arrow format files on
FDW infrastructure. Because of the columnar nature, it allows to load
the values which are
referenced by the query, thus, maximizes efficiency of the storage bandwidth.
Hi Mat,
On 2019/05/25 6:05, Mat Arye wrote:
> Hi,
>
> 11.3 included some change to partition table planning. Namely
> commit 925f46f ("Fix handling of targetlist SRFs when scan/join relation is
> known empty.") seems to redo all paths for partitioned tables
> in apply_scanjoin_target_to_paths.
On 2019/05/29 0:58, Andres Freund wrote:
> Hi,
>
>
>
>
>
> Add function
> linkend="functions-info-partition">pg_partition_root()
> to return top-most parent of a partition tree (Michaël Paquier)
>
>
>
>
>
>
>
>
On 2019/05/28 20:26, Amit Kapila wrote:
> On Tue, May 28, 2019 at 12:29 PM Amit Langote wrote:
>> Seeing that the crash occurs due to postgres_fdw relying on
>> es_result_relation_info being set when initializing a "direct
>> modification" plan on foreign tables managed by it, we could change the
Le mar. 28 mai 2019 à 21:28, Michael Paquier a écrit :
> On Tue, May 28, 2019 at 05:05:10PM +0200, Guillaume Lelarge wrote:
> >
> > linkend="catalog-pg-am">pg_am
> > - index access methods
> > + table and index access methods
> >
>
> Perhaps we could just say
Thanks!
I have changed the patch status as follows in commitfest [1]
Reviewer: Michael Paquier
Committer: Michael Paquier
Status: committed
[1]: https://commitfest.postgresql.org/23/2132/
Best regards,
On Tue, May 28, 2019 at 3:38 AM Michael Paquier wrote:
> On Mon, May 27, 2019 at
On Tue, May 28, 2019 at 05:05:10PM +0200, Guillaume Lelarge wrote:
>
> linkend="catalog-pg-am">pg_am
> - index access methods
> + table and index access methods
>
Perhaps we could just say "relation" here? That's the term used on
the paragraph describing pg_am.
--
On Tue, 28 May 2019 at 01:23, Ashwin Agrawal wrote:
> I think we will need to separate out the NOTICE message for concurrent and
> regular case.
>
> For example this doesn't sound correct
> WARNING: cannot reindex exclusion constraint index "public.circles_c_excl"
> concurrently, skipping
>
On Fri, Sep 28, 2018 at 9:30 AM Peter Eisentraut
wrote:
> On 16/09/2018 20:12, Douglas Doole wrote:
> > All this collation stuff is great, and I know users want it, but it
> > feels like were pushing them out of an airplane with a ripped parachute
> > every time the collation libraries change.
Hi everybody,
thanks a lot for your work.
This is just a stupid patch to fix some typos.
Thanks a lot to Magnus for the review.
You can see it also on GitHub,¹ if you prefer, or
apply it on top of today latest GIT.²
It passed "make check" on Linux.
Ciao,
Gelma
---
¹
Hi,
On 2019-05-27 12:40:07 +0200, Sascha Kuhl wrote:
> Where I can I find research on trees and indexing related to postgresql?
1) Please respect the list style of properly quoting responses inline,
and only responding to messages that are somewhat related to the
previous content
2) You
Dear moderator,
Can you inform me after you (as a mailing list) have changed something
related to my work. I like to keep track of my success.
Regards
Sascha Kuhl
Sascha Kuhl schrieb am Mo., 27. Mai 2019, 16:07:
> Would not
>
> Sascha Kuhl schrieb am Mo., 27. Mai 2019, 16:06:
>
>> To give
Where I can I find research on trees and indexing related to postgresql?
Sascha Kuhl schrieb am Mo., 27. Mai 2019, 11:14:
> Can you bring me to the research showing b-tree is equally performant? Is
> postgres taking this research into account?
>
> Jonah H. Harris schrieb am Sa., 25. Mai 2019,
On Fri, May 24, 2019 at 11:24 AM Noah Misch wrote:
> On Thu, May 23, 2019 at 06:56:49PM +0200, Magnus Hagander wrote:
> > On Thu, May 23, 2019, 18:54 Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
> > > To recap, the idea here was to change the default authentication
> methods
> >
Hi,
Add function pg_partition_root()
to return top-most parent of a partition tree (Michaël Paquier)
Add function pg_partition_ancestors()
to report all ancestors of a partition (Álvaro Herrera)
On Fri, May 24, 2019 at 5:05 PM Mat Arye wrote:
> Hi,
>
> 11.3 included some change to partition table planning. Namely
> commit 925f46f ("Fix handling of targetlist SRFs when scan/join relation is
> known empty.") seems to redo all paths for partitioned tables
> in
Hi,
On 2019-04-07 18:04:27 -0700, Andres Freund wrote:
> Here's a *prototype* patch for this. It only implements what I
> described for heap_multi_insert, not for plain inserts. I wanted to see
> what others think before investing additional time.
Pavan, are you planning to work on this for v13
Thanks of another round of review.
Robert Haas wrote:
> On Wed, Apr 24, 2019 at 10:48 AM Antonin Houska wrote:
> > Attached is the next version. It tries to address various problems pointed
> > out
> > upthread, including documentation.
>
> It's not immediately evident to me, perhaps because
Issue found while translating the v12 manual. I also fixed something that
was missing, as far as I understand it (first fix, the typo is the second
fix).
See patch attached.
Thanks.
--
Guillaume.
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 4c7e93892a..f81f3d4160
On 5/28/19 7:36 AM, RAJIN RAJ K wrote:
--> Function ' filter_id ' filters the ID's based on some conditions.
--> Input is set of ID's. (Not directly taking the input since there is
no provision to pass multiple rows to a function)
To be honest I cannot follow what you are trying to achieve
--> Function ' filter_id ' filters the ID's based on some conditions.
--> Input is set of ID's. (Not directly taking the input since there is no
provision to pass multiple rows to a function)
create function filter_id()
return table (id bigint)
begin
--> Assuming input table is already created
On Mon, May 27, 2019 at 11:20:28AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-27 14:18:12 -0400, Peter Eisentraut wrote:
> > I propose to add a column "command" to pg_stat_progress_create_index.
> > The sibling view pg_stat_progress_cluster already contains such a
> > column. This can help
Hi,
On 2019-04-18 21:02:57 +0900, Kyotaro HORIGUCHI wrote:
> Hello. As mentioned before [1], read_page callback in
> XLogReaderState is a cause of headaches. Adding another
> remote-controlling stuff to xlog readers makes things messier [2].
>
> I refactored XLOG reading functions so that we
On Tue, May 28, 2019 at 12:29 PM Amit Langote
wrote:
>
> On 2019/05/28 14:00, Alexander Lakhin wrote:
> > 28.05.2019 2:05, Amit Kapila wrote:
> >> ... If we read the comment atop ExecContextForcesOids
> >> [1] before it was removed, it seems to indicate that the
> >> initialization of
On Mon, May 27, 2019 at 11:20:28AM -0700, Andres Freund wrote:
> On 2019-05-27 14:18:12 -0400, Peter Eisentraut wrote:
>> I propose to add a column "command" to pg_stat_progress_create_index.
>> The sibling view pg_stat_progress_cluster already contains such a
>> column. This can help distinguish
On Mon, May 27, 2019 at 07:25:37PM -0700, Gurjeet Singh wrote:
> Please see attached the patch that corrects the file-level SQL comment that
> indicates which submodule of pgcrypto is being tested.
Thanks, committed. There was a second one in pgp-decrypt.sql.
--
Michael
signature.asc
> "Akim" == Akim Demaille writes:
>> Yeah, we've definitely found that resolving shift/reduce conflicts
>> via precedence declarations has more potential for surprising
>> side-effects than one would think.
Akim> That's why in recent versions of Bison we also provide a means to
Akim>
Hi Tomas,
Here is the patch, it's could be compatible with your patch and it focus on
when to regrow the batch.
On Tue, May 28, 2019 at 3:40 PM Hubert Zhang wrote:
> On Sat, May 4, 2019 at 8:34 AM Tomas Vondra
> wrote:
>
>> The root cause is that hash join treats batches as pretty much free,
|I have no problem with changing it to -r. -f seems a bit wrong to me,
|as it might read as a file. And in the future we might want to implement
|the ability to take full filename (with path), in which case it would
|make sense to use -f for that.
You could also use a long option for that
Kyotaro HORIGUCHI wrote:
> v3-0001 : Changed macrosas suggested.
This attachment is missing, please send it too.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
On Sat, May 4, 2019 at 8:34 AM Tomas Vondra
wrote:
> The root cause is that hash join treats batches as pretty much free, but
> that's not really true - we do allocate two BufFile structs per batch,
> and each BufFile is ~8kB as it includes PGAlignedBuffer.
>
> The OOM is not very surprising,
On 2019/05/28 14:00, Alexander Lakhin wrote:
> 28.05.2019 2:05, Amit Kapila wrote:
>> ... If we read the comment atop ExecContextForcesOids
>> [1] before it was removed, it seems to indicate that the
>> initialization of es_result_relation_info for each subplan is for its
>> usage in
Hi,
On Tue, May 28, 2019 at 12:54 PM Amit Langote
wrote:
> On 2019/05/27 22:02, Tom Lane wrote:
> > Amit Langote writes:
> >> On 2019/05/27 10:52, Shohei Mochizuki wrote:
> >>> I noticed returning a modified record in a row-level BEFORE UPDATE trigger
> >>> on postgres_fdw foreign tables do not
36 matches
Mail list logo
