Hi,
On Mon, Oct 19, 2020 at 4:58 PM Amul Sul wrote:
>
> Hi,
>
> Assertion added in commits 6b2c4e59d016 is failing with following test:
>
> CREATE TABLE sales
> (
> prod_id int,
> prod_quantity int,
> sold_monthdate
> ) PARTITION BY RANGE(sold_month);
>
> CREATE TABLE
On Tue, Oct 27, 2020 at 12:56 AM Tom Lane wrote:
>
> Alvaro Herrera writes:
> > On 2020-Oct-26, Craig Ringer wrote:
> >> also adds PQlibInfoPrint() which dumps PQlibInfo() keys/values to stdout.
>
> > Sounds useful. I'd have PQlibInfoPrint(FILE *) instead, so you can pass
> > stdout or whichever
On Mon, Oct 26, 2020 at 7:03 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Monday, October 26, 2020, Nikolay Samokhvalov
> wrote:
>>
>> Although, this triggers a question – should ANALYZE be automated in, say,
>> pg_restore as well?
>>
>
> Independent concern.
>
It's the same
Over in the thread at [1] it's discussed how our code for making
selectivity estimates using knowledge about FOREIGN KEY constraints
is busted in the face of EquivalenceClasses including constants.
That is, if fktab(a,b) is a 2-column FK reference to pktab(a,b)
and we have a query like
On Tue, Oct 27, 2020 at 8:51 AM Justin Pryzby wrote:
>
> On Fri, Oct 23, 2020 at 10:45:34AM +0530, Amit Kapila wrote:
> > On Fri, Oct 23, 2020 at 8:59 AM Amit Kapila wrote:
> >
> > While updating the streaming stats patch, it occurred to me that we
> > can write a better description spill_bytes
On Fri, Oct 16, 2020 at 9:26 PM Amit Kapila wrote:
>
>
> Cool, let me try to explain my thoughts a bit more. The idea is first
> (in standard_planner) we check if there is any 'parallel_unsafe'
> function/expression (via max_parallel_hazard) in the query tree. If we
> don't find anything
Forking this thread:
https://www.postgresql.org/message-id/fd93f1c5-7818-a02c-01e5-1075ac0d4...@iki.fi
They have been deprecated for a Long Time, so finally remove them for v14.
Four fewer exclamation marks makes the documentation less exciting, which is a
good thing.
>From
On Fri, Oct 23, 2020 at 10:45:34AM +0530, Amit Kapila wrote:
> On Fri, Oct 23, 2020 at 8:59 AM Amit Kapila wrote:
> >
> > On Fri, Oct 23, 2020 at 7:42 AM Masahiko Sawada
> > wrote:
> > >
> > > On Thu, 22 Oct 2020 at 20:34, Amit Kapila wrote:
> > > >
> > > > > > I have modified the description
On Wed, Oct 21, 2020 at 06:54:17AM -0500, Justin Pryzby wrote:
> On Tue, Oct 20, 2020 at 09:17:22PM -0400, Tom Lane wrote:
> > Justin Pryzby writes:
> > > I wonder if pg_upgrade should try to rmdir() the tablespace dirs before
> > > restoring global objects, allowing it to succeed, rather than
On Tue, Oct 27, 2020 at 8:21 AM Michael Paquier wrote:
>
> On Mon, Oct 26, 2020 at 09:09:17PM +0300, Anastasia Lubennikova wrote:
> > November commitfest will start just in a few days.
> > I'm happy to volunteer to be the CFM for this one. With a help of Georgios
> > Kokolatos [1].
>
> Thanks to
On Monday, October 26, 2020, Nikolay Samokhvalov
wrote:
>
>
> Although, this triggers a question – should ANALYZE be automated in, say,
> pg_restore as well?
>
Independent concern.
>
> And another question: how ANALYZE needs to be run? If it's under the
> user's control, there is an option to
On Mon, Oct 26, 2020 at 3:46 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> It would seem preferable to call the lack of auto-analyzing after these
> operations a bug and back-patch a fix that injects an analyze side-effect
> just before their completion. It doesn't have to be smart
On Tue, Oct 27, 2020 at 12:41 AM Alvaro Herrera
wrote:
> On 2020-Oct-26, Craig Ringer wrote:
>
> > Patch 0001 adds PQlibInfo(), which returns an array of key/value
> > description items reporting on configuration like the full version
> string,
> > SSL support, gssapi support, thread safety,
On Tue, 20 Oct 2020 at 22:02, Drouvot, Bertrand wrote:
>
> Hi,
>
> On 10/15/20 9:15 AM, Masahiko Sawada wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and know
> > the content is safe.
> >
On Mon, Oct 26, 2020 at 09:09:17PM +0300, Anastasia Lubennikova wrote:
> November commitfest will start just in a few days.
> I'm happy to volunteer to be the CFM for this one. With a help of Georgios
> Kokolatos [1].
Thanks to both of you for volunteering.
--
Michael
signature.asc
Description:
On Tue, Oct 20, 2020 at 12:25:48PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2020-Oct-18, Tom Lane wrote:
> >> It doesn't really seem sane to me to support two different build
> >> environments for thread_test, especially when one of them is so
> >> little-used that it can be broken
On Mon, Oct 26, 2020 at 05:04:09PM -0400, Bruce Momjian wrote:
> On Sat, Oct 17, 2020 at 01:50:26PM +, Daniel Westermann (DWE) wrote:
> > On Fri, Oct 9, 2020 at 11:08:32AM -0400, Bruce Momjian wrote:
> > >This is not applying to PG 12 or earlier because the patch mentions JIT,
> > >which was
On Mon, Oct 26, 2020 at 3:08 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> Hi all,
>
> As you all already know Postgres supports functions in index expressions
> (marked as immutable ofc) and for this special index the ANALYZE command
> creates some statistics (new pg_statistic
Hi Cary,
Thanks for taking a look. I agree there's a risk since there's more memory
usage on client side, and if you're dumping say millions of publicationTables
then that could be problematic.
I'd like to think this isn't any riskier than existing pg_dump code such as in
getTables(...)
Hi all,
As you all already know Postgres supports functions in index expressions
(marked as immutable ofc) and for this special index the ANALYZE command
creates some statistics (new pg_statistic entry) about it.
The problem is just after creating a new index or rebuilding concurrently
(using
On Sat, Oct 17, 2020 at 01:50:26PM +, Daniel Westermann (DWE) wrote:
> On Fri, Oct 9, 2020 at 11:08:32AM -0400, Bruce Momjian wrote:
> >This is not applying to PG 12 or earlier because the patch mentions JIT,
> >which was only mentioned in the PG bloom docs in PG 13+.
>
> Does that mean we
On Mon, Oct 26, 2020 at 3:09 PM Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
>
> Hello, hackers!
>
> November commitfest will start just in a few days.
> I'm happy to volunteer to be the CFM for this one. With a help of
> Georgios Kokolatos [1].
>
> It's time to register your patch
I started reading this patch. As a starting point I decided to post an
updated copy (v22), wherein I reverted the overwriting of
src/include/port/linux.h with the win32.h contents (?) and the inclusion
of in libpq-fe.h. If those are needed, some different
solution will have to be found.
Hello, hackers!
November commitfest will start just in a few days.
I'm happy to volunteer to be the CFM for this one. With a help of
Georgios Kokolatos [1].
It's time to register your patch in the commitfest, if not yet.
If you already have a patch in the commitfest, update its status and
On Mon, Oct 26, 2020 at 7:38 AM Julien Rouhaud wrote:
> Ah, yes this might lead to bad performance if the "fake wildcard"
> matches too many rows, but this shouldn't be a very common use case,
> and the only alternative for that might be to create trigrams for non
> alphanumerics characters. I
Alvaro Herrera writes:
> On 2020-Oct-26, Craig Ringer wrote:
>> also adds PQlibInfoPrint() which dumps PQlibInfo() keys/values to stdout.
> Sounds useful. I'd have PQlibInfoPrint(FILE *) instead, so you can pass
> stdout or whichever fd you want.
+1. Are we concerned about translatability of
At 2020-10-26 20:56:57 +0800, craig.rin...@enterprisedb.com wrote:
>
> $ ./build/src/interfaces/libpq/libpq.so
> VERSION_NUM: 14
> VERSION: PostgreSQL 14devel on x86_64-pc-linux-gnu, compiled by gcc (GCC)
> 10.2.1 20200723 (Red Hat 10.2.1-1), 64-bit
> CONFIGURE_ARGS:
On 2020-Oct-26, Craig Ringer wrote:
> Patch 0001 adds PQlibInfo(), which returns an array of key/value
> description items reporting on configuration like the full version string,
> SSL support, gssapi support, thread safety, default port and default unix
> socket path. This is for application
> On Oct 26, 2020, at 9:12 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Wed, Oct 21, 2020 at 11:45 PM Mark Dilger
>> wrote:
>>> Done that way in the attached, which also include Robert's changes from v19
>>> he posted earlier today.
>
>> Committed. Let's see what the buildfarm
Hello Aya Iwata
I've been hacking at this patch again. There were a few things I wasn't
too clear about, so I reordered the code and renamed the routines to try
to make it easier to follow.
One thing I didn't like very much is that all the structures and enums
were exposed to the world in
Rebased version of the patch.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/configure b/configure
index ace4ed5..deba608 100755
--- a/configure
+++ b/configure
@@ -700,6 +700,7 @@ LD
LDFLAGS_SL
LDFLAGS_EX
with_zlib
Robert Haas writes:
> On Wed, Oct 21, 2020 at 11:45 PM Mark Dilger
> wrote:
>> Done that way in the attached, which also include Robert's changes from v19
>> he posted earlier today.
> Committed. Let's see what the buildfarm thinks.
Another thing that the buildfarm is pointing out is
[WARN]
> 26 окт. 2020 г., в 06:05, Alexander Korotkov
> написал(а):
>
> Hi!
>
> On Mon, Sep 28, 2020 at 5:41 PM Andrey M. Borodin
> wrote:
>>> 28 авг. 2020 г., в 23:08, Anastasia Lubennikova
>>> написал(а):
>>>
>>> 1) The first patch is sensible and harmless, so I think it is ready for
>>>
Greetings,
* Jakub Wartak (jakub.war...@tomtom.com) wrote:
> I have I hope interesting observation (and nano patch proposal) on system
> where statistics freshness is a critical factor. Autovacuum/autogathering
> statistics was tuned to be pretty very aggressive:
>
Hi,
On October 26, 2020 7:13:15 AM PDT, Tom Lane wrote:
>Robert Haas writes:
>> On Mon, Oct 26, 2020 at 9:56 AM Mark Dilger
>> wrote:
hornet is still unhappy even after
321633e17b07968e68ca5341429e2c8bbf15c331?
>
>>> That appears to be a failed test for pg_surgery rather than for
Greetings,
* Craig Ringer (craig.rin...@enterprisedb.com) wrote:
> On Mon, Oct 19, 2020 at 11:16 AM Masahiko Sawada
> wrote:
> > The patch introduces only key management infrastructure but with no
> > key. Currently, there is no interface to dynamically add a new
> > encryption key.
>
> I'm a
Hi,
when group by multi-columns, it will multiply all the distinct values
together, and if one column is all null,
it also contributes 200 to the final estimate, and if the product is over
the relation size, it will be clamp.
So the the value of the agg rel size is not correct, and
Removing -docs as moderation won’t let me cross-post.
On Monday, October 26, 2020, David G. Johnston
wrote:
> On Monday, October 26, 2020, Jürgen Purtz wrote:
>
>> On 21.10.20 22:33, David G. Johnston wrote:
>>
>>
>> Two, I find the amount of detail being provided here to be on the
>> too-much
Zhenghua Lyu writes:
>It seems the function `get_variable_numdistinct` ignore the case when
> stanullfrac is 1.0:
I don't like this patch at all. What's the argument for having a special
case for this value? When would we ever get exactly 1.0 in practice?
regards,
Peter Eisentraut writes:
> The conceptual solution is to allow a client to register for a session
> which types it wants to always get in binary, unless it says otherwise.
OK.
> In the discussion in [0], I pondered a new protocol message for that,
> but after further thought, a GUC setting
Remove redundant processed parameter from zpq_read function.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/configure b/configure
index 071d050..12ae2dd 100755
--- a/configure
+++ b/configure
@@ -700,6 +700,7 @@ LD
LDFLAGS_SL
Robert Haas writes:
> On Mon, Oct 26, 2020 at 9:56 AM Mark Dilger
> wrote:
>>> hornet is still unhappy even after
>>> 321633e17b07968e68ca5341429e2c8bbf15c331?
>> That appears to be a failed test for pg_surgery rather than for amcheck. Or
>> am I reading the log wrong?
> Oh, yeah, you're
> On Oct 26, 2020, at 7:00 AM, Robert Haas wrote:
>
> On Mon, Oct 26, 2020 at 9:56 AM Mark Dilger
> wrote:
>> Much of the test in 0002 could be ported to work without committing the rest
>> of 0002, if the pg_amcheck command line utiilty is not wanted.
>
> How much consensus do we think we
I had a new look at this thread today, trying to figure out where we
are. I'm a bit confused.
One thing we have established: mmap()ing WAL files performs worse than
the current method, if pg_wal is not on a persistent memory device. This
is because the kernel faults in existing content of
On Mon, Oct 19, 2020 at 11:16 AM Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
The patch introduces only key management infrastructure but with no
> key. Currently, there is no interface to dynamically add a new
> encryption key.
I'm a bit confused by the exact intent and use cases
On Mon, Oct 26, 2020 at 9:56 AM Mark Dilger
wrote:
> Much of the test in 0002 could be ported to work without committing the rest
> of 0002, if the pg_amcheck command line utiilty is not wanted.
How much consensus do we think we have around 0002 at this point? I
think I remember a vote in favor
> On Oct 26, 2020, at 6:37 AM, Robert Haas wrote:
>
> On Fri, Oct 23, 2020 at 2:04 PM Tom Lane wrote:
>> Seems to work, so I pushed it (after some compulsive fooling
>> about with whitespace and perltidy-ing). It appears to me that
>> the code coverage for verify_heapam.c is not very good
On Fri, Oct 23, 2020 at 2:04 PM Tom Lane wrote:
> Seems to work, so I pushed it (after some compulsive fooling
> about with whitespace and perltidy-ing). It appears to me that
> the code coverage for verify_heapam.c is not very good though,
> only circa 50%. Do we care to expend more effort on
The attached patches propose new interfaces for exposing more configuration
and versioning information from libpq at runtime. They are to be used by
applications to obtain finer grained information about libpq's
configuration (SSL, GSSAPI, etc), to identify libpq binaries, and for
applications
On Sun, Oct 25, 2020 at 7:13 PM Julien Rouhaud wrote:
>
> On Sun, Oct 25, 2020 at 10:36 AM Thomas Munro wrote:
> >
> > On Fri, Oct 23, 2020 at 2:07 AM Julien Rouhaud wrote:
> > > While reviewing the changes, I found a couple of minor issues
> > > (inherited from the previous versions). It's
Greetings hackers,
I have I hope interesting observation (and nano patch proposal) on system where
statistics freshness is a critical factor. Autovacuum/autogathering statistics
was tuned to be pretty very aggressive:
autovacuum_vacuum_cost_delay=0 (makes autovacuum_vacuum_cost_limit
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
There are few "Stripping trailing CRs from the patch" and one
> On Mon, Oct 26, 2020 at 01:28:59PM +0400, Pavel Borisov wrote:
> > Thanks for your interest! FYI there is a new thread about this topic [1]
> > with the next version of the patch and more commentaries (I've created
> > it for visibility purposes, but probably it also created some confusion,
> >
> Thanks for your interest! FYI there is a new thread about this topic [1]
> with the next version of the patch and more commentaries (I've created
> it for visibility purposes, but probably it also created some confusion,
> sorry for that).
>
> Thanks!
I made a very quick look at your updates
On 20/10/2020 11:58, Peter Eisentraut wrote:
While working on another patch, I figured adding a
select_common_typmod() to go along with select_common_type() and
select_common_collation() would be handy. Typmods were previously
combined using hand-coded logic in several places, and not at all in
> On Mon, Oct 26, 2020 at 12:44:58PM +0400, Pavel Borisov wrote:
> >
> >
> > I wonder if anyone has plans to try again with this optimization in v14
> > cycle? The patches no longer apply thanks to the incremental sort patch,
> > but I suppose fixing that should not be extremely hard.
> >
> > I
po 26. 10. 2020 v 9:31 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> During the discussion on dynamic result sets[0], it became apparent that
> the current way binary results are requested in the extended query
> protocol is too cumbersome for some practical uses, and
>
>
> I wonder if anyone has plans to try again with this optimization in v14
> cycle? The patches no longer apply thanks to the incremental sort patch,
> but I suppose fixing that should not be extremely hard.
>
> I found this feature interesting and I'd like to join.
PFA the updated version of
Hi hackers,
It seems the function `get_variable_numdistinct` ignore the case when
stanullfrac is 1.0:
# create table t(a int, b int);
CREATE TABLE
# insert into t select i from generate_series(1, 1)i;
INSERT 0 1
gpadmin=# analyze t;
ANALYZE
# explain analyze select b, count(1) from t
Dear Fabien, Andres
I think your idea is good, hence I put some comments as a reviewer.
I focus on only the linux code because I'm not familiar with the Windows
system. Sorry.
[For patch A]
Please complete fixes for the documentation. At least the following sentence
should be fixed:
```
The
During the discussion on dynamic result sets[0], it became apparent that
the current way binary results are requested in the extended query
protocol is too cumbersome for some practical uses, and keeping that
style around would also make the proposed protocol extensions very
complicated.
The
Hi Ajin.
I checked the to see how my previous review comments (of v10) were
addressed by the latest patches (currently v12)
There are a couple of remaining items.
---
v12-0001. File: doc/src/sgml/logicaldecoding.sgml
COMMENT
Section 49.6.1
Says:
An
On 25/10/2020 23:56, Justin Pryzby wrote:
On Fri, Oct 23, 2020 at 11:09:26PM +0300, Heikki Linnakangas wrote:
Findings in detail follow.
Are you working on a patch for these ?
I pushed the patch I included in that email now, to remove the most
clear cases. I'm not planning to do anything
63 matches
Mail list logo
