#x27;t make that change without carefully
considering the implications for the callers.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Apr 23, 2025 at 11:59 AM Robert Haas wrote:
> heap_toast_insert_or_update care about HeapTupleHasExternal(), which
> seems like it might be a key point.
Care about HeapTupleHasVarWidth, rather.
--
Robert Haas
EDB: http://www.enterprisedb.com
I at least feel like DSA is a
pretty high-level system that I wouldn't want to count on being able
to access from a fairly-arbitrary point in the code, which is why I'm
quite astonished to hear Andres basically saying "don't worry, it's
all fine!". B
at Datum inside a container object (row, range,
array, whatever) detoasting is forced. If there's a clean and
inexpensive way to implement that, then you could avoid having
heap_toast_insert_or_update care about HeapTupleHasExternal(), which
seems like it might be a key point.
--
Robert Haas
EDB: http://www.enterprisedb.com
not have that
many compression methods ever, but you could have a large number of
dictionaries eventually.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Jan 3, 2025 at 8:44 AM Robert Haas wrote:
> > Actually, I noticed that we are failing to honor that in the places
> > where we inject "*SELECT*" and "*SELECT* %d" names, because that
> > code puts those names into RTE->alias not only RTE->eref
to store
the resulting data and then returned to the interrupted DSA operation,
would you expect the code to cope with that? I do not believe we have
anywhere enough guarantees about reentrancy for that to be safe.
--
Robert Haas
EDB: http://www.enterprisedb.com
inside the ReadStream? e.g. a
ParallelReadStream is really one ReadStream per participant, each with
a separate lock. Mostly you only touch your own, but if necessary you
can poke your fingers into other people's ReadStreams.
--
Robert Haas
EDB: http://www.enterprisedb.com
s to a certain set
of NUMA nodes; perhaps then they wouldn't want to use memory from
other nodes.
--
Robert Haas
EDB: http://www.enterprisedb.com
.
I also don't mind being wrong, of course. But I think it's better to
bet on making this like other things and then change strategy if that
doesn't work out, rather than starting out by making this different
from other things.
--
Robert Haas
EDB: http://www.enterprisedb.com
how CFI could be reachable from there
today, but even if it definitely isn't, I don't see why someone would
hesitate to add one in the future.
--
Robert Haas
EDB: http://www.enterprisedb.com
> "Estimates: capacity=N distinct keys=N lookups=N hit ratio=N.N%"
Is lookups=N here the estimated number of lookups i.e. what we think
nloops will end up being?
--
Robert Haas
EDB: http://www.enterprisedb.com
eems safer to bet on the pfree being a good idea than on the reverse,
because record_in() can be called lots of times in a single
transaction.
--
Robert Haas
EDB: http://www.enterprisedb.com
be the OID
> + * If processing a user-defined tablespace, the tsoid should be the OID
Yeah, I agree with both of these changes. Feel free to commit, unless
you want me to do it.
--
Robert Haas
EDB: http://www.enterprisedb.com
ead, does that
solve this whole problem, or is there more to it?
--
Robert Haas
EDB: http://www.enterprisedb.com
than a more "cooked" number like the estimated hit
ratio that was proposed in v1?
--
Robert Haas
EDB: http://www.enterprisedb.com
arrive at the rude discovery that 0dca5d68d is about 50% slower
> than 0dca5d68d^, because the old implementation builds a plan for fx()
> only once and then re-uses it throughout the query.
I agree that we should do something about this. I haven't reviewed
your patches but the approach
e, but I'm uncertain
myself what we ought to be doing here. I just wanted to raise the
issue.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Apr 7, 2025 at 11:59 AM Tom Lane wrote:
> Robert Haas writes:
> > The only thing that makes me a little bit sad is that we don't seem to
> > have added this to pg_stat_activity.
>
> Hmm, that seems like it'd be a completely separate discussion.
Yes,
that it was actually being done at parse time, and this complaint is
that it is scribbling on a parse-time data structure.
--
Robert Haas
EDB: http://www.enterprisedb.com
places that do GetBufferDescriptor(buffer - 1) and
similar. Alternating between 0-based indexing and 1-based indexing
like this seems rather error-prone somehow. :-(
--
Robert Haas
EDB: http://www.enterprisedb.com
e? I find
> the table_open/table_close pattern is quite common in the current
> code. In addition to get_relation_info(), I've also seen it in
> get_relation_constraints(), get_relation_data_width(), and others.
You're also right about this.
--
Robert Haas
EDB: http://www.enterprisedb.com
;s best to run pgindent before submitting.
I'd probably write the increments as ++ rather than += 1 but I'm not
sure if everyone would agree.
--
Robert Haas
EDB: http://www.enterprisedb.com
work ... or we're going to be committing to an API that we don't
really want to support.
To be clear, I'm not saying you're wrong, just that it's going to be
hard to change anything without making somebody unhappy.
--
Robert Haas
EDB: http://www.enterprisedb.com
hat
it's safe to assume that the local memory-context tree is in a
consistent state when CHECK_FOR_INTERRUPTS() is called. If there is
some existing discussion of this that I should read, please point me
in the right direction; I didn't see anything in a quick look through
the commit.
T
I don't think we should go back to the bad old days where we litigated
every case of marking something PGDLLIMPORT or not unless we have an
extremely good reason for so doing.
--
Robert Haas
EDB: http://www.enterprisedb.com
luded further down in the
email.
I don't know enough to opine on the questions about full vs. default,
or sequential scans.
--
Robert Haas
EDB: http://www.enterprisedb.com
le who have never even heard of it. Specify some time and data at
> UTC and everyone will understand.
+1.
--
Robert Haas
EDB: http://www.enterprisedb.com
the same time they
collect the pg_stat_activity data and so on; if you just add a column
to pg_stat_activity then the information just shows up as part of
routine data gathering.
--
Robert Haas
EDB: http://www.enterprisedb.com
ny
'data beyond EOF' messages are exactly that -- and it's not like the
user is going to guess that 'data beyond EOF' might mean that such a
thing occurred.
--
Robert Haas
EDB: http://www.enterprisedb.com
don't get matched with someone. On
the other hand, please do apply if you're interested: it's entirely
possible that some new committers will agree to participate, in which
case we have more spots, and in any case, somebody who might not have
agreed to mentor anyone else might ag
just put all their checks in one
> place rather than having to register a bunch of handlers.
Do you want to propose a patch?
--
Robert Haas
EDB: http://www.enterprisedb.com
i.e. you can
> never set conislocal=false in such a case).
Hmm. I think this is different from attislocal/attinhcount.
--
Robert Haas
EDB: http://www.enterprisedb.com
sed my pg_overexplain patch and attach that here.
--
Robert Haas
EDB: http://www.enterprisedb.com
v8-0001-pg_overexplain-Additional-EXPLAIN-options-for-deb.patch
Description: Binary data
On Tue, Mar 18, 2025 at 12:36 AM Masahiko Sawada wrote:
> > Cool. The commit message refers to 003_char_signedness, but the test
> > name is 005, not 003.
>
> Thank you for reviewing the patch. I've pushed the patch after fixing it.
Thanks for taking care of it (and so
on't want to rush into something
that we might later regret. I'm going to spend a bit more time
studying your patch next.
--
Robert Haas
EDB: http://www.enterprisedb.com
before or after any PostgreSQL version changes
that I'm doing. I'll be able to change the collation version at a time
when I'm not changing anything else and deal with JUST that fallout on
its own.
--
Robert Haas
EDB: http://www.enterprisedb.com
ve seen enough performance and correctness
problems with such code over the years to make me skeptical.
--
Robert Haas
EDB: http://www.enterprisedb.com
o work as in-core feature, and then there is
Andrei's desire for more hooks, which may very well also be a good
idea but not the same idea.
--
Robert Haas
EDB: http://www.enterprisedb.com
tial as possible, and this would detract from that. I
also don't know how long prewarming normally takes -- if it's fast
enough already, then maybe this doesn't matter. But if somebody is
having a problem with autoprewarm being slow and wants to implement a
multi-worker system to m
relhassubclass and attgenerated are retrieved before expression
> preprocessing, a relation's constraint expressions are retrieved when
> setting the relation's size estimates, and more.
Nonetheless I think we ought to be trying to consolidate more things
into get_relation_info(), not disperse some of the things that are
there to other places.
--
Robert Haas
EDB: http://www.enterprisedb.com
;d just
do a lot of VACUUM work for nothing. That's already a problem with
autovacuum in some scenarios, and I bet this would be way worse.
--
Robert Haas
EDB: http://www.enterprisedb.com
ral or some other user-focused
mailing list, not hackers. At any rate, I don't see how 1e4 could just
be "ignored", but as Maciek points out, 1e4 and 1 are of different
data types, which seems likely to be relevant somehow.
--
Robert Haas
EDB: http://www.enterprisedb.com
icExplainCleanup() in that
file to set, use, clear ActiveQueryDesc, and the rest of the system
might not need to know about it.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Apr 1, 2025 at 4:24 PM Jeff Davis wrote:
> On Tue, 2025-04-01 at 09:37 -0400, Robert Haas wrote:
> > I don't think I was aware of the open item; I was just catching up on
> > email.
>
> I lean towards making it opt-in for pg_dump and opt-out for pg_upgrade.
ntion, that can be simplified if "auto_explain"
> becomes a core feature. This could be a proposal taken up in 19.
For what we're talking about here, I don't think we would need to go
that far -- maybe put a few functions in core but no real need to move
the whole module into core. However, I don't rule out that there are
other reasons to do as you suggest.
--
Robert Haas
EDB: http://www.enterprisedb.com
orted subtransaction is popped off the
stack and we return to the parent transaction, we should be able to
log any query running at the outer level. If this is meant to imply
that something doesn't work in this scenario, perhaps there is
something about the design that needs fixing.
Does ActiveQueryDesc really need to be exposed to the whole system?
Could it be a file-level variable?
--
Robert Haas
EDB: http://www.enterprisedb.com
't have time before
feature freeze (not that we were necessarily in a great place to think
of committing this before feature freeze anyway, but it definitely
doesn't make sense now that I understand this problem).
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Apr 1, 2025 at 9:54 AM Christoph Berg wrote:
> Re: Robert Haas
> > > Another question is should we back-patch this? I believe we should (?)
> > I don't think this qualifies as a bug. The current wording isn't
> > factually wrong, just unhelpful. Even if i
es, fine, but my gut feeling
is that back-patching will make more people sad than it makes happy.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Mar 31, 2025 at 6:04 PM Jeff Davis wrote:
> On Mon, 2025-03-31 at 13:39 -0400, Robert Haas wrote:
> > +1. I think I said this before, but I don't think it's correct to
> > regard the statistics as part of the database. It's great for
> > pg_upgrade to
rom Rafael Castro, which I have been reviewing, but I am not
sure why we have two different patch sets here. Why is that?
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Mar 31, 2025 at 1:49 PM Tom Lane wrote:
> Robert Haas writes:
> > But why isn't it just as valuable to have two decimal places for the
> > estimate? I theorize that the cases that are really a problem here are
> > those where the row count estimate is be
abase. It's great for
pg_upgrade to preserve them, but I think doing so for a regular dump
should be opt-in.
--
Robert Haas
EDB: http://www.enterprisedb.com
data from 1 to 2, but
it's still the case that almost everything happens in
get_relation_info(), and there's now just exactly this 1 thing that is
done in a different place. That doesn't seem especially nice. I
thought the idea was going to be to move get_relation_info() to an
earlier stage, not s
nches b (cost=0.00..1.10 rows=10
width=364) (actual time=0.007..0.009 rows=10.00 loops=1)
But why isn't it just as valuable to have two decimal places for the
estimate? I theorize that the cases that are really a problem here are
those where the row count estimate is between 0 and 1 per row,
ing the tracking that we
already have for existence.
--
Robert Haas
EDB: http://www.enterprisedb.com
would be fairly strongly opposed to implementing RESTRICT and
CASCADE but having them only apply to role grants and not other
database objects.
I'm not entirely certain what the right thing to do is here, but I
don't think it's that.
--
Robert Haas
EDB: http://www.enterprisedb.com
something that couldn't be used with a regular EXPLAIN for
some reason. Or maybe the patch doesn't actually succeed in doing the
EXPLAIN with the correct namespace stack in all cases.
--
Robert Haas
EDB: http://www.enterprisedb.com
bility*.
Breakage means that the same supposedly-stable results return
different answers on the same data. Under that definition, continuing
under Unicode 15.1 does prevent breakage.
--
Robert Haas
EDB: http://www.enterprisedb.com
s like a somewhat naive
interpretation. You could also think it disables the feature,
effectively negating progressive_explain=on, but then you should start
to wonder why there are two GUCs. If you don't think either of those
things, then I think "do it once" is the only other reasonable
interpretation.
Of course, sometimes what I think turns out to be completely wrong!
--
Robert Haas
EDB: http://www.enterprisedb.com
g the instrumented plan
> every 1ms for example, IMHO.
I still have trouble understanding what that means. Is the interval
irrelevant except when progressive_explain = analyze?
--
Robert Haas
EDB: http://www.enterprisedb.com
it again. If you want to update the
view just once at query startup and not thereafter, you can set
progressive_explain_interval = 0.
--
Robert Haas
EDB: http://www.enterprisedb.com
server, that will be much sadder. So let's do something we're very
confident is safe. There is always the opportunity to change things in
the future if we're more confident about some questionable choice then
than we are now -- performance optimization can be done after the
fact. But if it's not stable, the only thing we're likely to change in
the future is to revert the whole thing.
--
Robert Haas
EDB: http://www.enterprisedb.com
we might also want some text there
explaining the general concept that EXPLAIN is now extensible via
loadable modules.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Mar 28, 2025 at 12:13 AM Man Zeng wrote:
> // PG_MODULE_MAGIC;
> PG_MODULE_MAGIC_EXT(
> .name = "pg_overexplain",
> .version = PG_VERSION
> );
Good catch, committed.
ake on my part. Thanks, committed.
--
Robert Haas
EDB: http://www.enterprisedb.com
grep for it and it's
mostly going to affect admin tools rather than all the queries
everywhere.
That's not to say that adding a second bool column instead of changing
the existing column's data type is necessarily the wrong way to go.
But I think you're overestimating the blast radius by quite a lot.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Mar 19, 2025 at 11:38 AM Sami Imseih wrote:
> ... as I made the hook signature match that of
> ParseExplainOptionList, so both pstate and the options list
> are now available to the hook.
This version LGTM, except it's not pgindent-clean.
--
Robert Haas
EDB: http://www.enterprisedb.com
trailing whitespace
> 2/ typos
Acknowledged, thanks.
--
Robert Haas
EDB: http://www.enterprisedb.com
gs we give
them. I'm not completely opposed to some other form of notification,
but I think it's OK if "we finally removed support for your extremely
old ICU version" is the driving force that makes people upgrade.
--
Robert Haas
EDB: http://www.enterprisedb.com
the recursive CTE would be rather confusing -- it's
probably best if the mandatory UNION operation is at the top level.
--
Robert Haas
EDB: http://www.enterprisedb.com
. I fear that's going to
be hard to make robust. Like, what happens if we're going around
trying to change ExecProcNode pointers while the calling code was also
going around trying to change ExecProcNode pointers? I can't quite see
how this won't result in chaos.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Mar 27, 2025 at 12:37 PM Robert Haas wrote:
> It's not a problem if UNION ALL is used within the initial_query and
> it's not a problem if UNION ALL is used within the iterated_query. But
> you can't apply ORDER BY to the result of the UNION, because the UNION
&g
N, because the UNION
is kind of fake -- we're not running the UNION as a single query,
we're running the two halves separately, the first once and the second
as many times as needed.
--
Robert Haas
EDB: http://www.enterprisedb.com
position on this particular patch, I
think it's entirely reasonable, as a concept, to think of making
Memoize work similarly to what other nodes already do.
--
Robert Haas
EDB: http://www.enterprisedb.com
ches is too annoying, I
think it would be reasonable to fix it only in master, but
back-patching seems OK too.
--
Robert Haas
EDB: http://www.enterprisedb.com
ide. Maybe there is some more dramatic rewording that is even
better, but there's probably some value in keeping it similar to what
people are used to seeing.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Mar 26, 2025 at 10:40 PM Tom Lane wrote:
> Robert Haas writes:
> > - -> Index Scan using daucus_id_idx on daucus v2_2 (actual
> > rows=0.12 loops=8)
> > + -> Index Scan using daucus_id_idx on daucus v2_2 (actual
> > rows=0.13 loops=8)
&
On Wed, Mar 26, 2025 at 2:09 PM Robert Haas wrote:
> Hearing no other votes against this, I have committed it, but now I
> wonder if that is going to break the buildfarm, because I just noticed
> that the changes I made in v9 seem not to have resolved the problem
> with debug_paralle
to have this still happen in the planner, but
sooner than it does now?
--
Robert Haas
EDB: http://www.enterprisedb.com
ng it in standard EXPLAIN, possibly only with VERBOSE, with
the caveats from the previous paragraph: if more-common node types are
also going to have a bunch of stuff like this, then we need to think
more carefully. If Memoize is exceptional in needing additional
information displayed, then I think it's fine.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Mar 26, 2025 at 2:34 PM Nikolay Shaplov wrote:
> В письме от среда, 26 марта 2025 г. 21:16:20 MSK пользователь Robert Haas
> написал:
> > The reason why I felt that way is
> > because you were using what seemed to me to be very strong language
> > over what seemed
.
Do either of you have any theory as to how removing a cast could cause
this behavior?
The only idea that occurs to me is a bug in gdb.
--
Robert Haas
EDB: http://www.enterprisedb.com
very minor issue. Phrases like "it will
make whole design inconsistent", "this is nasty thing", "you've just
changed the whole engine", and "this goes against all current practice
of options usage," seem like very strong wording and, in my opinion,
are just not accurate.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Feb 27, 2025 at 4:12 PM Robert Haas wrote:
> On Thu, Feb 27, 2025 at 4:08 PM Tom Lane wrote:
> > I was down on it to start with, on the grounds that it wasn't adding
> > enough ease-of-use to justify even a relatively small amount of added
> > code. I'
On Sat, Mar 22, 2025 at 12:10 PM Robert Haas wrote:
> I'm not going
> to insist on shipping this if I'm the ONLY one who would ever get any
> use out of it, but I doubt that's the case.
Hearing no other votes against this, I have committed it, but now I
wonder if th
, and you will never guess which one is in this
> case, until you finish reading, or one need to write a lot of comments.
I'm surprised that you think it will be hard to clarify this in the comments.
--
Robert Haas
EDB: http://www.enterprisedb.com
tion
is a win for the project overall. If we argued this much about every
design detail of my patches, I would have quit working on this project
long ago.
--
Robert Haas
EDB: http://www.enterprisedb.com
g hardware? I
don't really like "other external file system influence" because that
sounds like vague weasel-wording.
--
Robert Haas
EDB: http://www.enterprisedb.com
t seem to
have clearly been intended and wouldn't be a particularly sound design
principle anyway.
--
Robert Haas
EDB: http://www.enterprisedb.com
things with it that you
happen not to like.
--
Robert Haas
EDB: http://www.enterprisedb.com
l call AbortSubTransaction(), not AbortTransaction().
--
Robert Haas
EDB: http://www.enterprisedb.com
talking
about here, though.
> > - What happens if we crash?
>
> The replication slot we create is RS_TEMPORARY, so it disappears after
> restart. Everything else is as if the current implementation of CLUSTER ends
> due to crash.
Cool.
--
Robert Haas
EDB: http://www.enterprisedb.com
ore acute for this parameter than any other, and it
certainly does not seem like a good idea to make this parameter work
differently from the other ones.
--
Robert Haas
EDB: http://www.enterprisedb.com
, I think
it's surprising we haven't needed it sooner, and I think if an engine
is so opinionated about how things have to work that it can't
accommodate that, it's not a good idea for us to adopt it.
And if I'm wrong in thinking that, then I would like a detailed
technical argument explaining exactly why.
--
Robert Haas
EDB: http://www.enterprisedb.com
e, were pretty much ready
> -- we're having this discussion only to avoid the breakage. I could
> save us a bunch of time here and just push those patches, but I think
> the responsible thing here (the one we're less likely to regret) is not
> to.
Fair enough. I think I'
nge that appears to solve the problem in a very
natural way.
I don't understand why you're upset about this, and I don't think it's
fair to beat up Nathan for doing something that looks totally normal
without a really clear reason.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Mar 24, 2025 at 11:54 AM Tom Lane wrote:
> If somebody thinks of a better idea and is willing to do the legwork
> to make it happen, we can surely change to something else later on.
> Or invent another field with different semantics, or whatever.
Yeah, my thoughts exactly.
-
'd be
> introducing unnecessary complexity to the user, or at least we'd be trying
> to closely match the existing functionality in an attempt to hide this
> complexity from them.
+1. Giving the user the ability to set the option to a value called
"unset" does
1 - 100 of 2078 matches
Mail list logo
