> On Feb 24, 2018, at 2:01 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch, fixing some minor bitrot
> and duplicate OIDs.
The three patches apply cleanly, compile, and pass check-world.
You might consider using PointerGetDatum in compare_scalars_simple
rath
Peter Eisentraut writes:
> pg_class.relhaspkey doesn't seem to be used or useful for anything, so
> can we remove it? See attached patch.
We've discussed that at least twice before, and not pulled the trigger
for fear of breaking client code.
https://www.postgresql.org/message-id/flat/CAA-aLv7s
pg_class.relhaspkey doesn't seem to be used or useful for anything, so
can we remove it? See attached patch.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 01004383b0a3d30d519b9dc219b54c8d753df8ee Mon Sep 17
A heap rewrite during a DDL command publishes changes for relations
named like pg_temp_%u, which are not real tables, and this breaks
replication systems that are not aware of that. We have a hack in the
pgoutput plugin to ignore those, but we knew that was a hack. So here
is an attempt at a more
Hi,
Attached is an updated patch series, fixing duplicate OIDs and removing
opclasses for reltime/abstime data types, as discussed.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
0001-Pass-all-keys-to-B
Hi Aleksander,
This is Yan from Columbia University. I saw PostgreSQL is selected in
GSOC 2018 and pretty interested in the ideas of thrift data types support
that proposed by you. So, I want to prepare for a proposal based on this
idea. Can I have more detailed information of what documents or
> The change of the checksum state is WAL logged with a new xlog record. All
> the buffers written by the background worker are forcibly enabled full page
> writes to make sure the checksum is fully updated on the standby even if no
> actual contents of the buffer changed.
Hm. That doesn't soun
On Sat, Feb 24, 2018 at 10:51:22AM -0500, Peter Eisentraut wrote:
> On 2/17/18 08:48, Michael Paquier wrote:
>> Attached is what I have finished with. I have gathered the feedback
>> from everybody on this thread and I think that the result can satisfy
>> all the requirements mentioned:
>> - 0001
> On Feb 24, 2018, at 2:01 PM, Tomas Vondra
> wrote:
> Sadly, this patch series does not seem to move forward very much, and
> I'm not sure how to change that :-/
I'll take a look at the new patch set this evening. I have been using your
previous version of these patches applied against postg
Hi,
On 2018-02-24 22:56:57 +0100, Magnus Hagander wrote:
> On Sat, Feb 24, 2018 at 10:49 PM, Andres Freund wrote:
> > > We did consider doing it at a per-table basis as well. But this is also
> > an
> > > overhead that has to be paid forever, whereas the risk of having to read
> > > the database
& Services
0001-Keep-information-about-already-estimated-cl-20180224.patch.gz
Description: application/gzip
0002-multivariate-MCV-lists-20180224.patch.gz
Description: application/gzip
0003-multivariate-histograms-20180224.patch.gz
Description: application/gzip
On Sat, Feb 24, 2018 at 10:49 PM, Andres Freund wrote:
> On 2018-02-24 22:45:09 +0100, Magnus Hagander wrote:
> > Is it really that invisible? Given how much we argue over adding single
> > counters to the stats system, I'm not sure it's quite that low.
>
> That's appears to be entirely unrelated
On Sat, Feb 24, 2018 at 6:14 PM, Michael Banck
wrote:
> Hi,
>
> On Wed, Feb 21, 2018 at 09:53:31PM +0100, Magnus Hagander wrote:
> > We’ve also included a small commandline tool, bin/pg_verify_checksums,
> > that can be run against an offline cluster to validate all checksums.
>
> The way it is c
On 2018-02-24 22:45:09 +0100, Magnus Hagander wrote:
> Is it really that invisible? Given how much we argue over adding single
> counters to the stats system, I'm not sure it's quite that low.
That's appears to be entirely unrelated. The stats stuff is expensive
because we currently have to essent
On Sat, Feb 24, 2018 at 4:29 AM, Tomas Vondra
wrote:
> Hi,
>
> I see the patch also does throttling by calling vacuum_delay_point().
> Being able to throttle the checksum workers not to affect user activity
> definitely seems like a useful feature, no complaints here.
>
> But perhaps binding it t
On Sat, Feb 24, 2018 at 1:34 AM, Robert Haas wrote:
> On Thu, Feb 22, 2018 at 3:28 PM, Magnus Hagander
> wrote:
> > I would prefer that yes. But having to re-read 9TB is still significantly
> > better than not being able to turn on checksums at all (state today). And
> > adding a catalog column
On Fri, Feb 2, 2018 at 4:53 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> BTW wouldn't it be possible to derive "traditional" proof in relational
>> algebra, similarly to other transforms?
>
> Perhaps. The patch depends on CTID, but you could probably model that
> as a primary key in a proof.
I
Greg Stark writes:
> At my day job I've been doing a fair amount of routine query and
> schema optimization and I've noticed on particular query shape that
> has repeatedly caused problems, and it's one we've talked about
> before.
> select * from table where simple-restriction 0 OR (complex-subq
At my day job I've been doing a fair amount of routine query and
schema optimization and I've noticed on particular query shape that
has repeatedly caused problems, and it's one we've talked about
before.
select * from table where simple-restriction 0 OR (complex-subquery)
For example something l
Peter Eisentraut writes:
> Here is this patch updated. The client changes are now complete and all
> the tests pass. I have also rolled back the places where the code used
> prorettype to detect procedures and replaced this by the new facility.
I took a quick look through this and noted a few s
Hi,
On Wed, Feb 21, 2018 at 09:53:31PM +0100, Magnus Hagander wrote:
> We’ve also included a small commandline tool, bin/pg_verify_checksums,
> that can be run against an offline cluster to validate all checksums.
The way it is coded in the patch will make pg_verify_checksums fail for
heap files
On 2/17/18 08:48, Michael Paquier wrote:
> Attached is what I have finished with. I have gathered the feedback
> from everybody on this thread and I think that the result can satisfy
> all the requirements mentioned:
> - 0001 is a small patch which makes the SSL and LDAP test suite fail
> immediat
On 2/24/18 07:37, Michael Paquier wrote:
> On Fri, Feb 23, 2018 at 01:57:44PM -0500, Peter Eisentraut wrote:
>> Oh. I actually had that file as 0600 in my checked-out tree, probably
>> from earlier experiments. Fixed that. And I also changed it to make
>> another temp file that is explicitly 064
On Fri, Feb 23, 2018 at 11:08 AM, Antonin Houska wrote:
> I spent some more time thinking about this. What about adding a new strategy
> number for hash index operator classes, e.g. HTBinaryEqualStrategyNumber? For
> most types both HTEqualStrategyNumber and HTBinaryEqualStrategyNumber strategy
>
On Fri, Feb 23, 2018 at 9:15 PM, Alvaro Herrera
wrote:
> Clearly, for a few languages the current facilities are sufficient.
> If we make the process easier, we're likely to have more translations.
> Will there be people verifying the quality also?
It seems to me that making the process easier ha
On Fri, Feb 23, 2018 at 01:57:44PM -0500, Peter Eisentraut wrote:
> Oh. I actually had that file as 0600 in my checked-out tree, probably
> from earlier experiments. Fixed that. And I also changed it to make
> another temp file that is explicitly 0644, because we can't rely on that
> being the d
26 matches
Mail list logo
