> "Iwata, Aya" writes:
> > I'm going to propose libpq debug log for analysis of queries on the
> > application
> side.
> > I think that it is useful to determine whether the cause is on the
> > application
> side or the server side when a slow query occurs.
>
> Hm, how will you tell that really
On Sun, Sep 2, 2018 at 12:18 AM, Thomas Munro
wrote:
> On Fri, Aug 31, 2018 at 10:24 PM Dilip Kumar
> wrote:
>> On Fri, Aug 31, 2018 at 3:08 PM, Dilip Kumar wrote:
>> > As Thomas has already mentioned upthread that we are working on an
>> > undo-log based storage and he has posted the patch sets
Thank you Kato-san for testing.
On 2018/08/31 19:48, Kato, Sho wrote:
> Hi, Amit
>
> Great!
> With the total number of records being 6400, I benchmarked while increasing
> the number of partitions from 100 to 6400.
> Applying three all patches, 20% performance improved for 100 partitions.
>
> I
> Hello Bradley & Tatsuo-san,
>
>>> ... references to the protocol version lacks homogeneity.
>>> ... I'd suggest to keep "the vX.0 protocol" for a short version,
>>> and "the version X.0 protocol" for long ...
>>
>> I agree. Change made.
>
> Patch applies cleanly. Doc build ok.
>
> One part tal
On Fri, Aug 31, 2018 at 4:11 PM, Maksim Milyutin
wrote:
> On 08/31/2018 01:12 PM, Rafia Sabih wrote:
>
>
>
> On Fri, Aug 31, 2018 at 3:30 PM, Maksim Milyutin
> wrote:
>
>> On 08/31/2018 11:55 AM, Rafia Sabih wrote:
>>
>>
>> Adding to that this patch needs a rebase. And, please don't forget to ru
On Tue, Aug 28, 2018 at 6:43 PM Michael Paquier wrote:
>
> On Tue, Aug 28, 2018 at 11:21:34AM +0200, Peter Eisentraut wrote:
> > The files in question correspond to
> >
> > hash_i4_index
> > hash_name_index
> > hash_txt_index
>
> The hash index code has been largely refactored in v10, so I would
>
2018-09-03 3:49 GMT+02:00 Hubert Zhang :
> Thanks Pavel.
> Your patch did enforcement on storage level(md.c or we could also use
> smgr_extend). It's straight forward.
> But I prefer to implement disk_quota as a feature with following
> objectives:
> 1 set/alter disk quota setting on different dat
On Sat, Sep 1, 2018 at 10:28 AM Dilip Kumar wrote:
>
> On Sat, Sep 1, 2018 at 8:22 AM, Robert Haas wrote:
> > On Thu, Aug 30, 2018 at 7:27 AM, Amit Kapila
> > wrote:
> >
> > I wouldn't bother bumping HASH_VERSION. First, the fix needs to be
> > back-patched, and you certainly can't back-patch
Tomas Vondra writes:
> On 08/17/2018 11:23 PM, Tom Lane wrote:
>> Yeah, we've definitely hit such problems before. The geometric logic
>> seems particularly prone to it because it's doing more and subtler
>> float arithmetic than the rest of the system ... but it's not the sole
>> source of minus
Thanks Pavel.
Your patch did enforcement on storage level(md.c or we could also use
smgr_extend). It's straight forward.
But I prefer to implement disk_quota as a feature with following objectives:
1 set/alter disk quota setting on different database objects, e.g. user,
database, schema etc. not on
On 08/17/2018 11:23 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> Hmm, yeah. Based on past experience, the powerpc machines are likely to
>> stumble on this.
>
>> FWIW my understanding is that these failures actually happen in new
>> tests, it's not an issue introduced by this patch series.
>
>
I've pushed this, with some minor tweak, and backpatched to 11 (which is
where TRUNCATE decoding was introduced).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Robert Haas writes:
> On Fri, Aug 24, 2018 at 9:48 AM, Tom Lane wrote:
>> PQtrace() is utterly useless for anything except debugging libpq
>> internals, and it's not tremendously useful even for that. Don't
>> bother with that part.
> I think that improving the output format could help with tha
On Fri, Aug 24, 2018 at 9:48 AM, Tom Lane wrote:
> PQtrace() is utterly useless for anything except debugging libpq
> internals, and it's not tremendously useful even for that. Don't
> bother with that part.
I think that improving the output format could help with that a lot.
What it current pro
Robert Haas writes:
> On Tue, Aug 28, 2018 at 3:53 PM, Tom Lane wrote:
>> Parallel pg_restore generally assumes that the archive file is telling it
>> the truth about data dependencies; in particular, that a TABLE DATA item
>> naming a particular target table is loading data into exactly that tab
On Tue, Aug 28, 2018 at 3:53 PM, Tom Lane wrote:
> Parallel pg_restore generally assumes that the archive file is telling it
> the truth about data dependencies; in particular, that a TABLE DATA item
> naming a particular target table is loading data into exactly that table.
> --load-via-partition
On 3 September 2018 at 10:24, Robert Haas wrote:
> On Tue, Aug 28, 2018 at 9:39 AM, Tom Lane wrote:
>> I don't see any typos here; it looks to me more like a difference of
>> opinion about whether "information" is singular or plural. I don't
>> really feel a need to change the existing wording.
On Tue, Aug 28, 2018 at 11:38 AM, Alvaro Herrera
wrote:
> [TL;DR: I propose to set up abidiff.postgresql.org.]
Nice idea.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Aug 28, 2018 at 9:39 AM, Tom Lane wrote:
>> Opps. I mistakenly attached the incorrect patch. The correct one is
>> attached to this email.
>
> I don't see any typos here; it looks to me more like a difference of
> opinion about whether "information" is singular or plural. I don't
> really
On Mon, Aug 27, 2018 at 11:38 AM, Alexander Korotkov
wrote:
> The aspect I'm more concerned here about is whether we miss ability
> for detecting some of IO errors, if we don't distinguish new pages
> from pages whose tuples were removed by vacuum.
My main concern is correctness. If we ever have
On Tue, Aug 28, 2018 at 8:02 PM, Tom Lane wrote:
> I think this argument is a red herring TBH. The example Robert shows is
> of *zero* interest for dynahash or catcache, unless it's taking only the
> low order 3 bits of the OID for the bucket number. But actually we'll
> increase the table size
On Thu, Aug 30, 2018 at 7:45 PM, Chapman Flack wrote:
> On 08/30/18 15:35, Robert Haas wrote:
>> On Tue, Aug 28, 2018 at 6:30 AM, Peter Eisentraut
>> wrote:
>>> CALL compatible with the SQL standard. For example, if you have a
>>> function f1(IN a int, OUT b int), you would call it as SELECT f1(
On Thu, Aug 30, 2018 at 4:14 PM, Dave Cramer wrote:
> Reading this from the (JDBC) drivers perspective, which is probably a fairly
> popular one,
> We now have a standard that we can't really support. Either the driver will
> have to support
> the new PROCEDURE with the {call } mechanism or stay w
Hi all,
While looking at another patch for slot.c, I have noticed what looks
like incorrect use of errcode_for_file_access:
- errcode_for_file_access() is used with rmtree(), which makes no sense
as this comes from common/rmtree.c, and a warning already shows up using
%m.
- ERRCODE_DATA_CORRUPTED
On Fri, Aug 31, 2018 at 11:46:47AM -0700, Michael Paquier wrote:
> The checks will not be included in the final fix, still they look useful
> so I am planning to start a new thread on the matter as perhaps other
> folks have more and/or better ideas.
Pushed the fix down to 9.4, without the extra s
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > This requires a catversion bump, for which it may seem a bit late;
> > however I think it's better to release pg11 without a useless catalog
> > column only to remove it in pg12 ...
Yeah, I really don't think we want
On Sun, Sep 02, 2018 at 01:27:25PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > This requires a catversion bump, for which it may seem a bit late;
> > however I think it's better to release pg11 without a useless catalog
> > column only to remove it in pg12 ...
>
> Catversion bumps during
Alvaro Herrera writes:
> This requires a catversion bump, for which it may seem a bit late;
> however I think it's better to release pg11 without a useless catalog
> column only to remove it in pg12 ...
Catversion bumps during beta are routine. If we had put out rc1
I'd say it was too late, but
Hi
Already mentioned this in
https://postgr.es/m/20180831205020.nxhw6ypysgshjtnl@alvherre.pgsql
While trying to add support for foreign keys to partitioned tables, I
noticed that commit 8224de4f42cc ("Indexes with INCLUDE columns and
their support in B-tree") added a column to pg_constraint that
Hello Bradley & Tatsuo-san,
... references to the protocol version lacks homogeneity.
... I'd suggest to keep "the vX.0 protocol" for a short version,
and "the version X.0 protocol" for long ...
I agree. Change made.
Patch applies cleanly. Doc build ok.
One part talks about "terminating l
Hi
2018-09-02 14:18 GMT+02:00 Hubert Zhang :
> Thanks Chapman.
> @Pavel, could you please explain more about your second suggestion "implement
> some quotas on storage level?"
>
See attached patch - it is very simple - and good enough for our purposes.
Regards
Pavel
> We will not keep the
Thanks Chapman.
@Pavel, could you please explain more about your second suggestion "implement
some quotas on storage level?"
We will not keep the long-lived processes attach to all databases(just like
you mentioned servers with thousands of databases)
And you are right, we could share ideas with a
32 matches
Mail list logo
