On Sat, Feb 8, 2020 at 8:05 AM Ranier Vilela wrote:
>
> Hi,
> I am migrating my applications that use postgres client from msvc 2010
> (32bits) to msvc 2019 (32 bits).
> Compilation using msvc 2019 (64 bits), works very well.
> But the build using msvc 2019 (32 bit) is not working.
> The 32-bit P
On Sat, Feb 8, 2020 at 12:10 AM Andres Freund wrote:
>
> Hi,
>
> On 2020-02-04 10:15:01 +0530, Kuntal Ghosh wrote:
> > I performed the same test in pg11 and reproduced the issue on the
> > commit prior to a4ccc1cef5a04 (Generational memory allocator).
> >
> > ulimit -s 1024
> > ulimit -v 30
>
On Sun, Aug 25, 2019 at 1:56 PM Tom Lane wrote:
> I agree that teaching opclasses to say whether this is okay is a
> reasonable approach.
I've begun working on this, with help from Anastasia.
My working assumption is that I only need to care about
opclass-declared input data types (pg_opclass.op
On Sun, 9 Feb 2020 at 01:53, Tomas Vondra wrote:
>
> On Sat, Feb 08, 2020 at 07:47:24AM -0800, Andres Freund wrote:
> >Hi,
> >
> >On February 8, 2020 7:08:26 AM PST, Tomas Vondra
> > wrote:
> >>On Sat, Feb 08, 2020 at 02:48:54PM +0900, Masahiko Sawada wrote:
> >>>On Sat, 8 Feb 2020 at 03:24, Andr
On Sat, Feb 8, 2020 at 10:24 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Sat, Feb 08, 2020 at 03:22:17PM +0100, Tomas Vondra wrote:
> > So in this case the skip scan is ~15x slower than the usual plan (index
> > only scan + unique). The reason why this happens is pretty simple - to
> >
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Our previous
>> discussions about what privilege level is needed to look at
>> pg_stat_statements info were all made against a background assumption
>> that you needed some extra privilege to set up the view in the first
>> place.
Tomas Vondra writes:
> On Sat, Feb 08, 2020 at 07:47:24AM -0800, Andres Freund wrote:
>> On February 8, 2020 7:08:26 AM PST, Tomas Vondra
>> wrote:
I don't think it's very likely we'll ever merge any openssl code into
our repository, e.g. because of licensing. But we already have AES
>
On Sat, Feb 08, 2020 at 04:24:40PM +0100, Dmitry Dolgov wrote:
On Sat, Feb 08, 2020 at 03:22:17PM +0100, Tomas Vondra wrote:
I've done some testing and benchmarking of the v31 patch, looking for
regressions, costing issues etc. Essentially, I've ran a bunch of SELECT
DISTINCT queries on data set
Justin Pryzby writes:
> On Thu, Dec 27, 2018 at 10:24:17AM -0300, Alvaro Herrera wrote:
>> I think it would be valuable to have those ALTER TABLE variants that rewrite
>> the table do so using the cluster order, if there is one, instead of the heap
>> order, which is what it does today.
> That's
On Sat, Feb 08, 2020 at 07:47:24AM -0800, Andres Freund wrote:
Hi,
On February 8, 2020 7:08:26 AM PST, Tomas Vondra
wrote:
On Sat, Feb 08, 2020 at 02:48:54PM +0900, Masahiko Sawada wrote:
On Sat, 8 Feb 2020 at 03:24, Andres Freund wrote:
Hi,
On 2020-02-07 20:44:31 +0900, Masahiko Sawada
Hi,
On February 8, 2020 7:08:26 AM PST, Tomas Vondra
wrote:
>On Sat, Feb 08, 2020 at 02:48:54PM +0900, Masahiko Sawada wrote:
>>On Sat, 8 Feb 2020 at 03:24, Andres Freund wrote:
>>>
>>> Hi,
>>>
>>> On 2020-02-07 20:44:31 +0900, Masahiko Sawada wrote:
>>> > Yeah I'm not going to use pgcrypto fo
> On Sat, Feb 08, 2020 at 03:22:17PM +0100, Tomas Vondra wrote:
>
> I've done some testing and benchmarking of the v31 patch, looking for
> regressions, costing issues etc. Essentially, I've ran a bunch of SELECT
> DISTINCT queries on data sets of various size, number of distinct values
> etc. The
Hi,
I wonder if this is meant to support external KMS systems/services like
Vault (from HashiCorp) or CloudHSM (from AWS) or a hardware HSM. AFAICS
the current implementation does not allow storing keys in such external
systems, right? But it seems kinda reasonable to want to do that, when
alread
On Sat, Feb 08, 2020 at 02:48:54PM +0900, Masahiko Sawada wrote:
On Sat, 8 Feb 2020 at 03:24, Andres Freund wrote:
Hi,
On 2020-02-07 20:44:31 +0900, Masahiko Sawada wrote:
> Yeah I'm not going to use pgcrypto for transparent data encryption.
> The KMS patch includes the new basic infrastructu
Forking this thread
https://www.postgresql.org/message-id/20181227132417.xe3oagawina7775b%40alvherre.pgsql
On Wed, Dec 26, 2018 at 01:09:39PM -0500, Robert Haas wrote:
> ALTER TABLE already has a lot of logic that is oriented towards being
> able to do multiple things at the same time. If we adde
OK,
A couple more comments based on quick review of the patch, particularly
the part related to planning:
1) create_skipscan_unique_path has one assert commented out. Either it's
something we want to enforce, or we should remove it.
/*Assert(distinctPrefixKeys <= list_length(pathnode->path.pa
Hi,
I've done some testing and benchmarking of the v31 patch, looking for
regressions, costing issues etc. Essentially, I've ran a bunch of SELECT
DISTINCT queries on data sets of various size, number of distinct values
etc. The results are fairly large, so I've uploaded them to github
https
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Julien Rouhaud writes:
> >>> Probably NO, if only because you'd need additional privileges
> >>> to use these anyway:
> >>> pg_stat_statements
>
> > But the additional privileges are global, so assuming the extension
> > has been properly setup
On Fri, Feb 07, 2020 at 05:25:43PM +0100, Dmitry Dolgov wrote:
On Thu, Feb 06, 2020 at 09:22:20PM +0900, Kyotaro Horiguchi wrote:
At Thu, 6 Feb 2020 11:57:07 +0100, Dmitry Dolgov <9erthali...@gmail.com> wrote
in
> > On Thu, Feb 06, 2020 at 10:24:50AM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 5
Hello,
It seems you are not the first to be interested in such feature.
There was a similar extension used in "incremental view maintenance"
testing:
https://github.com/nuko-yokohama/pg_fraction
didn't tryed it myself.
Regards
PAscal
--
Sent from: https://www.postgresql-archive.org/PostgreSQ
20 matches
Mail list logo
