a thing, and no
one has wanted to take it on.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rogress on FDWs
and some other things.
So I'd really like to get this into 9.6. I'm happy to put it into the
March commitfest if someone will volunteer to review it.
Comments?
regards, tom lane
upper-planner-pathification-1.patch.gz
Description: upper-planner
of rel->reltarget.width. See for example
> the attached while I bumped on this email..
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Amit Langote writes:
> Attached fixes a typo:
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
dy has a similar mechanism (see PLpgSQL_function.use_count)
which you could probably copy. But I'd advise that this is a separate
matter to be addressed in a separate patch; it has little to do with the
nominal subject matter of this patch.
regards, tom lane
--
Sent v
Robert Haas writes:
> I'll abstain from the question of whether this patch is too late in
> coming (but the answer is probably "yes") and instead volunteer to
> review it.
OK, I've put it into the commitfest. Thanks for volunteering!
reg
is to fix all these
omissions, not to decide that we're not maintaining this documentation
anymore. Alvaro, I think this one's in your court.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
?
To make this work, you'd need a way to distinguish privileges installed
by initdb from those changed later.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
code behind it?
Cool!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> To make this work, you'd need a way to distinguish privileges installed
>> by initdb from those changed later.
> To replicate whatever the current ACL is, we don't actually need to
> make such a di
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> No, the point of it would be to not have pg_dump scripts overriding
>> installed-by-default ACLs. A newer PG version might have different
>> ideas about what those should be. I don't think this is exac
mation to recursive subquery_planner calls so that we're not leaving
this kind of optimization to chance. But the patch is big enough already,
so that (and a lot of other things) are getting left for later.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-h
if they were new rows.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Greg Stark writes:
> On Tue, Mar 1, 2016 at 2:30 PM, Tom Lane wrote:
>> There are a couple of
>> regression test cases that change plans for the better, but it's sort of
>> accidental. Those cases look like
>>
>> select d.* from d left join (select * fro
cheap, and in order to minimize the delta in this patch I did
not worry much about avoiding duplicate calls of it. That's another
thing in a long list of things to do later ;-). There might be other
pain points I haven't recognized yet.
regards, tom l
author input.
And I don't see the value of having them in a new CF until the
author does something.
> I am even more unclear on "Rejected". My instinct says we should refuse
> a move-to-next-cf for such patches.
Right. Rejected is dead, it shouldn't propaga
score DESC, time_taken ASC;
> or wrapped
> SELECT count(*) FROM ( SELECT *
>FROM "index_cond_test"
>WHERE (final_score, time_taken) < (20, 11)
>ORDER BY final_score DESC, time_taken ASC) q;
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hat don't keep their
data in shared buffers. Also, if you insist on keeping the data in
shared memory, there will be a fixed limit on how many temp tables
can exist at one time.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
d.
I guess this could also be addressed by having two separate aclitem[]
columns, one that is expected to be frozen after initdb and one for
user-added grants.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
isfied if we can make COPY deal with the sum
of a line's fields exceeding 1GB.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[ trimming -novice from the cc list ]
Jeff Janes writes:
> On Tue, Mar 1, 2016 at 7:40 AM, Tom Lane wrote:
>> (Problem is reproducible in 9.5 and HEAD, but not 9.4.)
> Bisects down to:
> 606c0123d627b37d5ac3f7c2c97cd715dde7842f is the first bad
e other changes that sometimes mask the problem.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Petr Jelinek writes:
> On 01/03/16 18:37, Tom Lane wrote:
>> However, I'm not sure that's 100% of the issue, because in playing around
>> with this I was having a harder time reproducing the failure outside of
>> Tobias' example than I expected. There may be m
index-only scan is legal.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to be reverted
outright and returned to the authors for redesign. There are too many
things wrong with it and too little reason to think that we have to have
it in 9.5.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Steele writes:
> I volunteered a while back to be the CFM and I haven't seen any other
> volunteers or objections to my offer.
> I am still ready, eager, and willing!
I haven't heard any other volunteers either. You have the conn, sir.
to argue very hard.
BTW, is there an ability to rename a CF once it's in the app? Seems like
that would reduce the stakes here.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ng some null columns. Right now,
the presence of any nulls disables the MATCH improvement, but it would
still apply if the null(s) are in lower-order columns. I'm not sure
if that case comes up often enough to justify checking the flag bit
twice per iteration, but it might.
e a localized fix.
I doubt we want to get into making _bt_first's API contract tighter.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
urns out that the server is not OK anyway.
BTW, is anyone checking the other side of this, ie "COPY IN" with equally
wide rows? There doesn't seem to be a lot of value in supporting dump
if you can't reload ...
regards, tom lane
--
Sent via pgsql-hac
PostgreSQL only supports Tcl 8.4 or later.
#endif
If we don't do that, I'm at least going to put in a similar #error for
Tcl 8.0; but I really think we ought to just say 8.4 is the minimum.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
le this code unconditionally.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hat we
don't move the goalposts on software compatibility without knowing it.
When we come across a good reason to desupport an old Perl or Tcl or
whatever version, we'll do it; but having to add another ten lines or
so of code doesn't seem like a good reason.
regards,
th the TAP tests' infrastructure's habit of being utterly
impenetrable when it's not working. My small amount of Perl-fu is
not sufficient to debug this.
perl-5.10.1-141.el6_7.1.x86_64
perl-Test-Harness-3.17-141.el6_7.1.x86_64
perl-Test-Simple-0.92-141.el6_7.1.x86_64
ll see if the older
buildfarm members like it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
if there's
anything older in our buildfarm, I don't know about it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Tue, Mar 1, 2016 at 10:22 AM, Tom Lane wrote:
>> I think the default pgbench queries are too simple to have any possible
>> benefit from this patch. It does look like you're seeing some extra
>> planning time, which I think is likely due to re
ow.
I'm too lazy to check the exact wording, but I don't think there's a hard
and fast promise in the protocol doc that one CopyData message == one row.
So we could probably subdivide a very wide line into multiple messages.
regards, tom lane
--
Sent via pgs
are/perl5/Test/Builder.pm has
sub details {
my $self = shift;
return @{ $self->{Test_Results} };
}
and line 1798 is the "return" statement in that. I still lack enough
Perl-fu to decipher this, though.
regards, tom lane
--
Sent via pgsql-hackers mail
Jim Nasby writes:
> [ pltcl_objects_2.patch ]
I've pushed this with some minor fixes, as well as the followup work
mentioned in this thread.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
7;ll have to continue to provide pg_proc entries with
the old signatures to support pg_upgrade. Will fix.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
er stages is going to need
major revision to play with this.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
clear that it's a debugging tool
and not something we expect end users to use.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jim Nasby writes:
> On 3/1/16 5:06 PM, Tom Lane wrote:
>> If we don't do that, I'm at least going to put in a similar #error for
>> Tcl 8.0; but I really think we ought to just say 8.4 is the minimum.
> Just confirmed that should be completely reasonable. I'll t
queries.
Anybody else want to check performance on simple scan/join queries?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
in the past about extensible
approaches to subscripting, though I haven't got time to troll the
archives for it right now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ompared with the other version,
Cool! If you come across any points where it seems like it could be
done better or more easily, that would be tremendously valuable feedback
at this stage.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
ake the query
succinct here. Explicitness is easier and safer too, so why not?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
56077...@sss.pgh.pa.us
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2016-03-02%2023%3A34%3A10
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nteresting planning choices implicit.
My general feeling about this is that I don't want it to be a blocker
for getting the basic patch in, but I'll happily consider further
refactoring of individual path types once we're over that hump.
If you wanted to start on a follow-on patch to
At this point, the earliest the cmake work could land is 9.7,
and TBH I do not think we are committed to landing it at all. So it'd
behoove us to fix at least HEAD, and probably older branches too,
to work with up-to-date MSVC.
regards, tom lane
--
Sent via pgsql-hac
Alvaro Herrera writes:
> Tom Lane wrote:
>> Yeah. At this point, the earliest the cmake work could land is 9.7,
>> and TBH I do not think we are committed to landing it at all. So it'd
>> behoove us to fix at least HEAD, and probably older branches too,
>> to
than it had to be.)
> In general, and I'm sure this is not a huge surprise, most of this
> looks very good to me. I think the design is sound and that, if the
> performance is OK, we ought to move forward with it.
Thanks. As I told Teodor last night, I can't reproduce a perf
Robert Haas writes:
> On Thu, Mar 3, 2016 at 2:19 PM, Tom Lane wrote:
>> Thanks. As I told Teodor last night, I can't reproduce a performance
>> issue here with pgbench-style queries. Do you have any thoughts about
>> how we might satisfy ourselves whether there
01edc6c6f065cd25f77f63ab31aff085d6ac, but apparently Tom forgot to
> grep for other uses of that identifier name.
Duh :-(. Actually, do we need that sleep at all anymore? Seems like
wait_for_stats ought to cover it.
regards, tom lane
--
Sent via pgsql-hackers mailin
it? The pg_sleep is sort of half-bakedly substituting for
a proper wait.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera writes:
> Tom Lane wrote:
>> That's what it looks like to me. I now think that the apparent
>> connection to parallel query is a mirage. The reason we've only
>> seen a few cases so far is that the flapping test is new: it
>> wad added in comm
benefit of not having it there?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Fri, Mar 4, 2016 at 11:03 AM, Tom Lane wrote:
>> Well, that would make the function more complicated, but maybe it's a
>> better answer. On the other hand, we know that the stats updates are
>> delivered in a deterministic order, so
constant of
> 10 is a little unsettling but I think we can live with it.
+1. "No knob" is a huge win.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e this.
I'll work on the performance testing next. Barring unsatisfactory
results from that, I think this could be committable in a couple
of days.
regards, tom lane
upper-planner-pathification-2.patch.gz
Description: upper-planner-pathification-2.patch.gz
--
Sent via pgs
Robert Haas writes:
> On Fri, Mar 4, 2016 at 11:17 AM, Tom Lane wrote:
>> Huh? Parallel workers are read-only; what would they be doing sending
>> any of these messages?
> Mumble. I have no idea what's happening here.
OK, after inserting a bunch of debug logging I h
antee the presence of sed. I thought the proposal
to get rid of the psed dependence in favor of some more perl code was
pretty sane.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
Amit Kapila writes:
> On Fri, Mar 4, 2016 at 11:31 PM, Tom Lane wrote:
>> (BTW, I found what seemed to be a couple of pre-existing bugs of
>> the same kind, eg create_mergejoin_path was different from the
>> other two kinds of join as to setting parallel_degree.)
>
fied patch right now, but will spend some
time filling in the missing pieces first.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
but measurably at the bottom of the time range.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
lel_safe in
upper paths. In the short term that will have the effect of
marking all upper paths as parallel-unsafe, but that's at least a
safe default that we can improve later.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Attached is a version that addresses today's concerns, and also finishes
filling in the loose ends I'd left before, such as documentation and
outfuncs.c support. I think this is in a committable state now, though
I plan to read through the whole thing again.
re
gain.
Sigh, forgot to press the magic button. Let's try that again.
regards, tom lane
upper-planner-pathification-3.patch.gz
Description: upper-planner-pathification-3.patch.gz
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
include state into the blob.
(Note: I've not actually read this version of your patch, although
I could make time for that next week sometime.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
Amit Kapila writes:
> On Sat, Mar 5, 2016 at 10:11 PM, Tom Lane wrote:
>> Is there some reason why hash and nestloop are safe but merge isn't?
> I think it is because we consider to pushdown hash and nestloop to workers,
> but not merge join and the reason for not pushi
only two places that would have to be fixed anyway.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
not
want to swear that we've been 100% consistent. 22021 means "this
character is bad in isolation", AFAICT, so it didn't seem appropriate
for the conversion scenario.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Joe Conway writes:
> Something like the attached what you had in mind?
That's much better, but is there a reason you're using exit(2)
and not exit(EXIT_FAILURE) ?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Joe Conway writes:
> On 03/06/2016 05:47 PM, Tom Lane wrote:
>> That's much better, but is there a reason you're using exit(2)
>> and not exit(EXIT_FAILURE) ?
> Only because I was trying to stick with what was originally in
> src/bin/pg_controldata/pg_controldata.c
sane cost numbers without that knowledge?)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
expect that this will get committed, not even as a "temporary fix".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Amit Kapila writes:
> On Mon, Mar 7, 2016 at 9:13 AM, Tom Lane wrote:
>> AFAICS, those are about generating partial paths, which is a completely
>> different thing from whether a regular path is parallel-safe or not.
> Okay, but the main point I wanted to convey is th
Peter Geoghegan writes:
> In summary, I think it's surprising that a max_parallel_degree of 1
> doesn't disable parallel workers entirely.
Yeah, it's not exactly clear what "1" should mean that's different
from "0", in this case.
hose disadvantages and do it
anyway ... but this doesn't sound like a very good reason.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e decorated with parallel_safe, parallel_degree, etc annotations.
The existing documentation is barely adequate to explain what those fields
mean for primitive scan nodes; it's impossible for anyone but you to
know what they are supposed to mean for joins and higher-level nodes.
N COSTS OFF in
the regression tests, no test failures ensued :-(.
I've pushed it now; we'll soon see if the buildfarm finds any problems.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
upport for the
SQL-standard information_schema views. So if you write a pkey-identifying
query against those views, you'd have some chance of a solution that
actually did work everywhere.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Rowley writes:
> The attached fixes a small spelling error in a comment.
"grep" found another one. Pushed, thanks!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
David Rowley writes:
> The attached fixes a small error in the logicaldecoding docs.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
Joe Conway writes:
> Committed/pushed with exit(EXIT_FAILURE)
Thanks! I lit off a new run on gaur/pademelon to confirm. Should
have results in six hours or so...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
ing on Author. There's
still time to consider a rewrite in this 'fest, if you can get it done
in a week or two.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
implementations to confirm exactly what
behavior they implement. If we're to go against what the spec seems to
say, I want to see a whole lot of evidence that other people do it
consistently in a different way.
regards, tom lane
--
Sent via pgsql-hackers mai
;tsm_handler" appears to be invalid
pg_dump: WARNING: typtype of data type "void" appears to be invalid
$
The datatypes being complained of are evidently all the pseudo-types.
I haven't looked into the code to figure out why this happens.
The dump is produced anyway, so it
ball. Thus, any files that perl is used
to produce have to be shipped in tarballs.
However, there definitely *is* a hard requirement on perl for Windows
builds, even from tarballs, and I thought this patch was only about
the Windows build?
regards, tom lane
--
Sent v
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> pg_dump: WARNING: typtype of data type "any" appears to be invalid
> This is fixed in my changes to pg_dump, though I didn't expect you'd be
> able to hit them in released versions and so had
a kluge) and instead hot-wire things so that stuff in pg_catalog
is excluded even if it would otherwise match the inclusion lists.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan writes:
> On 03/08/2016 10:43 AM, Tom Lane wrote:
>> However, there definitely *is* a hard requirement on perl for Windows
>> builds, even from tarballs, and I thought this patch was only about
>> the Windows build?
> Michael's patch proposes to repla
actually, but it seems like this
might be enough of a win to be worth committing. Probably the main
argument against it is that we'd have to remember to maintain the list
of things-to-check-before-using-the-fast-path.
Thoughts?
regards, tom lane
diff --git a/src/b
Alvaro Herrera writes:
> Tom Lane wrote:
>> So maybe we should drop the hunk you've got there (which frankly seems a
>> bit of a kluge) and instead hot-wire things so that stuff in pg_catalog
>> is excluded even if it would otherwise match the inclusion lists.
> No
ng xmin horizon and inspecting the
visibility map, but I find it hard to believe there aren't plenty.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Wed, Jan 20, 2016 at 5:09 PM, Tom Lane wrote:
>> Um, I would like to review it, but I doubt I'll find time before the end
>> of the month.
> Tom, can you pick this up?
Yes, now that I've gotten out from under the pathification thing,
I
etter suggestion right now
though.
* Not sure if new regression test cases would be appropriate. The changes
in the existing cases seem a bit unfortunate actually; I'm afraid that
this may be defeating the original intent of those tests.
I'm setting this back to Waiting on Author.
Robert Haas writes:
> Unique Joins - This patch has had a lot of review and discussion. It
> would be best if Tom Lane looked at it.
Yeah, I'll pick it up soon. I've basically been kicking as much as
I could down the road for the last couple of months, trying to get the
pathi
anything in this patch that touches the same queries
that changed plans in my previous patch.
I do think that the verbosity this adds to the EXPLAIN output is not
desirable at all, at least not in text mode. Another line for every
darn join is a pretty high price.
1 - 100 of 48047 matches
Mail list logo
