to tell people about them. But opinions
will vary, and that's fine. I just mentioned my opinion since you
seemed to be asking. :-)
--
Robert Haas
EDB: http://www.enterprisedb.com
me. My initial
> reaction is that it shouldn't be included, but I do see some items with a
> similar scope, such as "Remove some SPI macros."
I wouldn't mention either this or "Remove some unused SPI macros".
--
Robert Haas
EDB: http://www.enterprisedb.com
x27;t expected to cause this to happen, but did anyway.
We also discovered that core dumps weren't *completely* disabled. They
still occurred for segmentation faults, but not for abort traps.
So, if anyone's having a similar problem, check with your IT
department or try with a fresh OS i
de is written
in C (or C++, Rust, etc.). Trying to run procedural code at that point
doesn't seem reasonable.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Aug 27, 2024 at 4:07 PM Robert Haas wrote:
> I think that the beginning of add_paths_to_joinrel() looks like a
> useful spot to get control. You could, for example, have a hook there
> which returns a bitmask indicating which of merge-join, nested-loop,
> and hash join will
x27;d like there to be a
way forward here but at the moment I'm not quite sure what it is.
--
Robert Haas
EDB: http://www.enterprisedb.com
ard the distinction between
similarly-named wait events won't find it prohibitively difficult to
look over the list of all the wait events they ever see and decide
which ones they'd like to merge for reporting purposes. But a user who
really needs things separated out and finds that they aren't is simply
out of luck.
--
Robert Haas
EDB: http://www.enterprisedb.com
We'd still all have master
branches in our local repositories and somebody might accidentally try
to push one of those branches back to the upstream repository and the
buildfarm and lots of other tooling would get confused and it would
all be a mess for a while, but the history itself wou
he 1970s
or 1980s (like me!) over what feels good to people who learned to code
in the 2010s or 2020s, we will definitely run out of developers at
some point.
--
Robert Haas
EDB: http://www.enterprisedb.com
hout really
stopping to think about it. If on the other hand the two are lumped
together as sdjgs and a user needs to distinguish them, they can't. So
I see unique names as having much more upside than downside.
--
Robert Haas
EDB: http://www.enterprisedb.com
plexity
> than it's worth. And it's absurdly expensive to fork to return an error. Way
> more expensive than just having postmaster send an error and close the socket.
The tricky case is the one where the client write() -- or SSL_write() -- blocks.
--
Robert Haas
EDB: http://www.enterprisedb.com
+ pg_log_error("pg_waldump cannot read from a tar");
"tar" isn't normally used as a noun as you do here, so I think this
should say "pg_waldump cannot read tar files".
Technically, the position of this check could lead to an unnecessary
failure, if -n wasn't specified but pg
y traffic lights on commitfest.postgresql.org yet.
Should I #blamemagnus?
--
Robert Haas
EDB: http://www.enterprisedb.com
I would rather that you didn't add simple_ptr_list_destroy_deep()
given that you don't need it for this patch series.
+
"\"%s\" unexpected file in the tar format backup",
This doesn't seem grammatical to me. Perhaps change this to: file
\"%s\" is not expected in a tar format backup
+ /* We
hey
> depend on that stuff.
I think that's a bit pointless considering that we don't do it in any
of the other cases. I'd rather be consistent with our usual practice.
But if it ends up in a separate header file that's still better than
the status quo.
--
Robert Haas
EDB: http://www.enterprisedb.com
but I digress). And there must be
tons of third-party code out there that knows how to interpret a text
or bytea varlena. So it's not like we have some principled
project-wide policy of hiding these implementation details. At first
look, numeric seems like an outlier.
--
Robert Haas
EDB: http://www.enterprisedb.com
a branch. I know
that's not how it worked in CVS, but CVS was a very long time ago.
If we rename master to main or devel or something, we'll have to
adjust the way we speak again, but that's not a reason to keep using
the wrong terminology for the way things are now.
--
Robert Haas
EDB: http://www.enterprisedb.com
people don't give up on writing the code that they
want to write -- they just cut-and-paste private declarations/code
into their own source tree, which is WAY worse than if we just put the
stuff in a .h file.
--
Robert Haas
EDB: http://www.enterprisedb.com
t a belated +1 for this and any other cruft removal we can do in
SPI-land.
--
Robert Haas
EDB: http://www.enterprisedb.com
Do we still need to maintain this backward compatibility?
> Could we consider removing the RULE privilege entirely?
8.2 is a long time ago. If it's really been dead since then, I think
we should remove it.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Aug 16, 2024 at 11:29 AM Robert Haas wrote:
> > I'll split this patch like that, to make it easier to compare and merge
> > with Jelte's corresponding patches.
>
> That sounds great. IMHO, comparing and merging the patches is the next
> step here and would b
On Mon, Aug 26, 2024 at 8:40 AM Robert Haas wrote:
> On Fri, Aug 23, 2024 at 3:40 PM Jacob Champion
> wrote:
> > Agreed on the name. I've attached a reconfigured version of v15-0003,
> > with an extension that should hopefully not throw off the cfbot, and a
> &g
On Mon, Sep 9, 2024 at 12:09 AM Richard Guo wrote:
> Fixed.
Thanks to Alexander for the very good catch and to Richard for pushing the fix.
(I started to respond to this last week but didn't quite get to it
before I ran out of time/energy.)
--
Robert Haas
EDB: http://www.enterprisedb.com
sql
> metacommands added in d55322b0da60 should become handy. That's on my
> TODO spreadsheet of things to look at, but I did not come back to it
> yet.
That's interesting, but it sort of seems like it's reinventing the
wheel, vs. the one-line change that I proposed.
--
Robert Haas
EDB: http://www.enterprisedb.com
se it got lost in the
shuffle, +1 for changing this, unless somebody can make a compelling
argument why 2 * max_connections isn't WAY too many.
--
Robert Haas
EDB: http://www.enterprisedb.com
people are simply going to use partitioning, a lot of indexes, etc?
>
> So yeah, I agree we probably need a more fundamental rethink. I don't
> think we can just keep optimizing the current approach, there's a limit
> of fast it can be. Whether it's not locking
nd wonderful workarounds. Let's try again in 18.
The problem I have with this is that we just released RC1. I suppose
if we have to make this change it's better to do it sooner than later,
but are we sure we want to whack this around this close to final
release?
--
Robert Haas
EDB: http://www.enterprisedb.com
archy-aware
lock manager. I don't know. But this feels like very old, crufty tech.
There's probably something more state of the art that we could or
should be doing.
--
Robert Haas
EDB: http://www.enterprisedb.com
#x27;t done any experiments, but it
> seems fairly doable - of course, not sure if it might be more expensive
> compared to compile-time constants.
I agree that this is a potential problem but it sounds like the idea
works well enough that we'd probably still come out quite
ul results for sequences; so then why do we need
to change the code to enable it?
--
Robert Haas
EDB: http://www.enterprisedb.com
measuring,
> that would be helpful.
I'm not really measuring anything at this point, just recalling the
many previous times when add_path() has been discussed as a pain
point.
--
Robert Haas
EDB: http://www.enterprisedb.com
e acceptable. So my guess is that this
is a dead end, unless there's a clever idea that I'm not seeing.
--
Robert Haas
EDB: http://www.enterprisedb.com
#x27;t understand why that path wins on cost, unless it's just that
the paths compare fuzzily the same, in which case it kind of goes to
my earlier point about not really having the statistics to know which
way is actually going to be better.
--
Robert Haas
EDB: http://www.enterprisedb.com
es during join estimation, I
believe aggregate estimation tends to be far worse.
--
Robert Haas
EDB: http://www.enterprisedb.com
ets you disable the paths
that you don't prefer. Once you do that, add_path() takes care of the
rest: disabled paths lose to non-disabled paths, and disabled paths
lose to more expensive disabled paths.
--
Robert Haas
EDB: http://www.enterprisedb.com
ose that we should:
- Add a call to
pgstat_report_query_id(queryDesc->plannedstmt->queryId, false) to the
top of ExecutorRun() with an appropriate comment.
- Fix the incorrect comment mentioned above.
- Back-patch to all releases containing 4f0b0966c86 i.e. v14+.
Thoughts?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Aug 28, 2024 at 3:23 PM Jeff Davis wrote:
> On Tue, 2024-08-27 at 15:11 -0400, Robert Haas wrote:
> > - control over scan methods
> > - control over index selection
> > - control over join methods
> > - control over join order
>
> I suggest we split
ct who are not native speakers of English, and are thus more
likely to be tripped up by obscure usages.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Aug 28, 2024 at 8:37 AM Robert Haas wrote:
> This has a big advantage over what I proposed yesterday in that it's
> basically declarative. With one call to the hook, you get all the
> information about the join order that you could ever want. That's
> really nice.
H
tely that it did by setting a certain flag, or maybe there
> should be routines exposed by the core to do that ?
This could be really useful when things go wrong and someone is trying
to figure out from an EXPLAIN ANALYZE output what in the world
happened. I'm not sure exactly what makes sense to do here but I think
we should come back to this topic after we've settled some of the
basics.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Aug 28, 2024 at 9:41 AM Peter Geoghegan wrote:
> On Wed, Aug 28, 2024 at 9:35 AM Robert Haas wrote:
> > > If you think it's important to have this info on all indexes then I'd
> > > prefer the pgstat approach over adding a field in IndexScanDescData.
>
, 259c96fa8f, 449cdcd486, 3ca43dbbb6, 2a679ae94e, 3a82c689fd,
> fbd4321fd5, d53a4286d7, c086896625, 4e5d6c4091.
> I didn't include fix 04158e7fa3 into patches because Robert Haas
> objected to its use.
To be clear, I'm not against 04158e7fa3. I just don't think
that's much more
> elegant than this.
I agree with this analysis. I don't see why IndexScanDesc would ever
be the right place for this.
--
Robert Haas
EDB: http://www.enterprisedb.com
hat reaction too initially, but I think that was mostly
because "Primitive Index Scans" seemed extremely unclear. I think
"Index Searches" is pretty comprehensible, honestly. Why shouldn't
someone be able to figure out what that means?
Might make sense to restrict this to VERBOSE mode, too.
--
Robert Haas
EDB: http://www.enterprisedb.com
ke good decisions, but there might well be
another explanation.
> I will continue to do benchmark on this feature.
>
> [1] https://github.com/tenderwg/eager_agg
Thanks!
--
Robert Haas
EDB: http://www.enterprisedb.com
all the paths but an extension can arrange for some of
them to be disabled. Then all the right things will happen naturally;
we'll only be leaving some CPU cycles on the table. Which isn't
amazing, but I don't think it's a critical defect either, and we can
try to improve things later if we want to.
--
Robert Haas
EDB: http://www.enterprisedb.com
the point is that if you did want some of that, or
something else, it doesn't look difficult to feed that information
through to the places where you would need it to be available.
Thoughts?
--
Robert Haas
EDB: http://www.enterprisedb.com
e either some very good documentation or some well-written
example implementations, we'll get more traction here.
--
Robert Haas
EDB: http://www.enterprisedb.com
ch doesn't seem convincing to me at all. If, for non-btree
indexes, the number of index searches will always be the same as the
loop count, then surely there is some way to avoid cluttering the
output for non-btree indexes with output that can never be of any use.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Aug 27, 2024 at 12:56 PM Tom Lane wrote:
> Robert Haas writes:
> > In that vein, here's a new patch set where I've added a second patch
> > that allows extensions to control choice of index.
>
> I'm minus-several on this bit, because that is a solved p
if (name != NULL && strchr("aeiouAEIOU", name[0]) != NULL)
index->disabled = true;
--
Robert Haas
EDB: http://www.enterprisedb.com
maybe something similar for indexes,
although that is less clear. The details aren't quite clear, which is
probably part of why we haven't done anything yet.
But this patch set is really more about enabling use cases where the
user wants an extension to take control of the plan more ex
On Mon, Aug 26, 2024 at 3:28 PM Robert Haas wrote:
> Well, I agree that this doesn't address everything you might want to
> do, ... I will very happily propose more things to
> address the other problems that I know about ...
In that vein, here's a new patch set where I'
t I don't think it should be the design center for what we
implement, because it looks nothing like what existing PG or non-PG
systems do, at least in my experience.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Aug 26, 2024 at 1:37 PM Tom Lane wrote:
> Robert Haas writes:
> > I'm somewhat expecting to be flamed to a well-done crisp for saying
> > this, but I think we need better ways for extensions to control the
> > behavior of PostgreSQL's query planner.
>
some level of consistency here.
Sure, consistency is good, all other things being equal, but just
saying "well this used to work one way and now it works another way"
isn't enough to say that there is a bug, or that something should be
changed.
--
Robert Haas
EDB: http://www.enterprisedb.com
ommas, add or remove whatever, and then SET
the new option value. If that were something lots of users were doing
all the time, then I think it might make a lot of sense to have a
built-in solution to make it easier, but I doubt that's the case.
--
Robert Haas
EDB: http://www.enterprisedb.com
hat this only works for
relkind='r', but since relam=heap is only possible for relkind='r',
there's not really any other reasonable interpretation, which IMHO
makes this pretty specific about what the problem is. Maybe you just
find it confusing, but that's a bit different from whether it's
explicit enough.
--
Robert Haas
EDB: http://www.enterprisedb.com
eve it
would be concretely useful to pg_hint_plan in particular. But all that
said, as much as anything, I want to get some feedback on what
approaches and trade-offs people think might be acceptable here,
because there's not much point in me spending a bunch of time writing
code that every
greppable
anyway and it doesn't really matter. But surely changing something
like rs_flags to just flags is just making everyone's life harder:
[robert.haas pgsql]$ git grep rs_flags | wc -l
38
[robert.haas pgsql]$ git grep flags | wc -l
6348
--
Robert Haas
EDB: http://www.enterprisedb.com
LGTM. Objections?
--
Robert Haas
EDB: http://www.enterprisedb.com
L or it can set m->bad and
either of those change the result of should_verify_control_data() and
should_verify_checksum(), but none of that is obvious when you just
look at this. Admittedly, the code in master isn't brilliant in terms
of making it obvious what's happening either, but I think this is
worse. I'm not really sure what I think we should do about that yet,
but I'm uncomfortable with it.
--
Robert Haas
EDB: http://www.enterprisedb.com
id
because the AM cannot support it", "this path is crazy expensive", and
"the user told us not to do it this way" are three different things,
and signalling two or more of them in the same way muddies the water
in a way that I don't like. API breaks are
not to call add_path when NULL is returned.
There might be a more elegant way to do it with more refactoring, but
the above seems good enough.
--
Robert Haas
EDB: http://www.enterprisedb.com
on the
> extension maintainer, which is valid, but I don't see why an extension
> maintainer can't raise an issue or ask a question here.
I'm certainly not saying that extension maintainers can't raise issues
or ask questions here. I just feel that the problem could have been
analyzed a bit more before posting.
--
Robert Haas
EDB: http://www.enterprisedb.com
bly better to add a more modest value, to avoid overflow.
You could add a million or so and be far away from overflow while
presumably still being more disabled than any other path.
--
Robert Haas
EDB: http://www.enterprisedb.com
d it seems to me that if that person
had studied this case and the commit message for e2225346, they would
have likely understood what had happened pretty quickly. Do you think
that's an unfair feeling on my part?
--
Robert Haas
EDB: http://www.enterprisedb.com
ths to the direct
Aggregate path will look too much like comparing random numbers. We
need to know whether the combination of the FinalizeAggregate step and
the PartialAggregate step will be more or less expensive than a plain
old Aggregate, but how can we tell that if we don't have accurate
cardina
On Thu, Aug 15, 2024 at 5:02 PM Nathan Bossart wrote:
> On Wed, Aug 07, 2024 at 02:01:30PM -0400, Robert Haas wrote:
> > Also, for the notes to be useful, we'd probably need some conventions
> > about how we, as a project, want to use them. If everyone does
> > somet
more serious problems turn up, it's a revert. If
we start to get some of these changes made now, there's a lot more
room for error. Let's take advantage of the time available while we
still have it.
--
Robert Haas
EDB: http://www.enterprisedb.com
improvement for the node above it, but I don't quite see
why that would happen in this case.
--
Robert Haas
EDB: http://www.enterprisedb.com
artition, you still have to make at
least one new partition. But possibly that syntax is worth having
anyway, because it would be a lot quicker in the case of a highly
asymmetric split. On the other hand, maybe even splits are much more
likely and we don't really need it. I don't know.
--
Robert Haas
EDB: http://www.enterprisedb.com
Hi,
In response to some concerns raised about this fix on the
pgsql-release list today, I spent some time investigating this patch.
Unfortunately, I think there are too many problems here to be
reasonably fixed before release, and I think all of SPLIT/MERGE
PARTITION needs to be reverted.
I focus
nt to see what
people are actually sad (or, potentially, happy) about.
--
Robert Haas
EDB: http://www.enterprisedb.com
gt;) again and write it to the "correct" batch.
Does skipping this cause any problem if some attributes are toasted?
I suppose not, just something to think about.
--
Robert Haas
EDB: http://www.enterprisedb.com
idea.
Nobody else has responded. Hence, I'm withdrawing this patch. If a
bunch of people show up to say we should really do this, we can
revisit the issue when that happens.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Aug 2, 2024 at 12:53 PM Robert Haas wrote:
> On Fri, Aug 2, 2024 at 12:51 PM Tom Lane wrote:
> > That absolutely is the expectation, and we'd better be careful not
> > to break it.
>
> I have every intention of not breaking it. :-)
I went ahead and commi
gn of doing the initial pruning
> before AcquireExecutorLocks() and focus on hashing out any bugs and
> issues of that design.
That's also an option. It probably has issues too, but I don't know
what they are exactly.
--
Robert Haas
EDB: http://www.enterprisedb.com
;m kinda hoping it was just a hardware issue.
Barring objections or other similar trouble reports, I think we should
just close out this open item.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Aug 20, 2024 at 6:53 PM David Rowley wrote:
> On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
> > I like trying to use ONLY somehow.
>
> Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
> or as a table modifier like gram.y's extended_re
uite
> right to me - surely the ONLY should be attached to the table name?
> An alternative would be:
>
> ANALYZE [ ( option [, ...] ) ] [ONLY] [ table_and_columns [, ...] ]
>
> Any feedback or advice would be great.
I like trying to use ONLY somehow.
--
Robert Haas
EDB: http://www.enterprisedb.com
person who designed the current protocol version
numbering scheme seems to have had in mind, even if the implementation
to make it a reality has been a bit lacking.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Aug 20, 2024 at 12:42 PM David G. Johnston
wrote:
> I'm wondering why we are indicating that minor versions of the protocol are
> even a real thing.
Because that concept is already a part of the existing wire protocol.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Aug 20, 2024 at 11:53 AM Jelte Fennema-Nio wrote:
> On Tue, 20 Aug 2024 at 17:46, Robert Haas wrote:
> > I personally like this less than both (a) adding a new function and
> > (b) redefining the existing function as Jelte proposes. It just seems
> > too clever to me
sonally like this less than both (a) adding a new function and
(b) redefining the existing function as Jelte proposes. It just seems
too clever to me.
--
Robert Haas
EDB: http://www.enterprisedb.com
LTER TABLE variants and think it through. But maybe the problems
aren't that bad.
It does seem like constraints can change the plan. Imagine the
partition had a CHECK(false) constraint before and now doesn't, or
something.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Aug 19, 2024 at 1:52 PM Tom Lane wrote:
> Robert Haas writes:
> > But that seems somewhat incidental to what this thread is about.
>
> Perhaps. But if we're running into issues related to that, it might
> be good to set aside the long-term goal for a bit and c
honestly. All of the opinions
about what we ought to do seem to be based on the firm conviction that
X or Y or Z will not work, rather than on the confidence that A or B
or C will work. Yet I'm inclined to believe this problem is solvable.
--
Robert Haas
EDB: http://www.enterprisedb.com
I think we normally try to replan rather than let a stale plan be used
because we want to not fail, because users don't like failure. If the
design you propose here would make failures more (or less) frequent,
then that's a problem (or awesome).
--
Robert Haas
EDB: http://www.enterprisedb.com
people want to do.
I feel like we're finally in a position to get some things done here
and this doesn't seem like the point to get stuck on. YMMV, of course.
--
Robert Haas
EDB: http://www.enterprisedb.com
made this particular mistake. I
think a much more common usage error is exiting the catch-block
without either throwing an error or rolling back a subtransaction. But
YMMV, of course.
--
Robert Haas
EDB: http://www.enterprisedb.com
emails to those who want them.
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
rs. Depending
> on the request either by Varnish or nginx.
I'm still unable to access any https://git.postgresql.org/ URL.
--
Robert Haas
EDB: http://www.enterprisedb.com
f wish you had brought this argument up earlier. Maybe
you did and I missed it, but I was under the impression that you were
just arguing that "nobody will notice or care," which is a quite
different argument than what you make here.
--
Robert Haas
EDB: http://www.enterprisedb.com
sed. The startup
message also contains a version number, and changes the format of that
message are also not proposed.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Aug 16, 2024 at 3:53 PM Robert Haas wrote:
> +int64 num = strtoi64(relpath, &suffix, 10);
Hit send too early. Here, seems like this should be strtoul(), not strtoi64().
The documentation of --format seems to be cut-and-pasted from
pg_basebackup and the language isn&#
On Wed, Aug 14, 2024 at 12:44 PM Robert Haas wrote:
> On Wed, Aug 14, 2024 at 9:20 AM Amul Sul wrote:
> > I agree with keeping verify_backup_file() separate, but I'm hesitant
> > about doing the same for verify_backup_directory().
>
> I don't have time today to go
ther checking for it. But these
examples show that some people do. If Jacob found these examples this
easily, there are probably a bunch of others.
It's not worth breaking existing code to avoid adding one new libpq
entrypoint. Let's just add the new function and move on.
ll be clearer what the right thing to do is; or
maybe other people will be more certain of what The Right Thing To Do
is than I am myself; but there's no rush to finalize a decision right
this minute.
--
Robert Haas
EDB: http://www.enterprisedb.com
t this patch like that, to make it easier to compare and merge
> with Jelte's corresponding patches.
That sounds great. IMHO, comparing and merging the patches is the next
step here and would be great to see.
--
Robert Haas
EDB: http://www.enterprisedb.com
1 - 100 of 1617 matches
Mail list logo
