e
engineering".
This is a patch about which multiple people have expressed concerns.
You're trying to jam a heavily redesigned version in at the last
minute without adequate review. Please don't do that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
unexpected modification to one of those tables, but the
behavior, even if not insecure, will certainly be wrong.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Sat, Mar 24, 2018 at 8:11 AM, Simon Riggs wrote:
> On 24 March 2018 at 11:58, Robert Haas wrote:
>> On Sat, Mar 24, 2018 at 7:42 AM, Simon Riggs wrote:
>>> I suggest we focus on the engineering. I've not discussed this patch
>>> with Pavan offline.
>>
&g
On Sat, Mar 24, 2018 at 8:16 AM, Robert Haas wrote:
> On Thu, Mar 22, 2018 at 7:13 PM, Peter Geoghegan wrote:
>> While I think this this particular HINT buglet is pretty harmless, I
>> continue to be concerned about the unintended consequences of having
>> multiple RTEs for
ookup would be performed using a new
snapshot -- not all under one snapshot.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
pe]
> return (bgworker_main_type)
That's probably going to mean we need, or at least want, to do
something about this at some point. Warning-free compiles are
desirable.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Mar 26, 2018 at 12:16 PM, Simon Riggs wrote:
> On 26 March 2018 at 16:09, Robert Haas wrote:
>> On Mon, Mar 26, 2018 at 5:53 AM, Simon Riggs wrote:
>>> Since we now have MVCC catalog scans, all the name lookups are
>>> performed using the same snapshot so in t
e originally-reported problem. I haven't tested this
beyond verifying that it passes the regression test, but I've run out
of time for today.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
0004-Rewrite-the-code-that-applies-scan-join-targets
s in a worker.
Regarding cursor_to_xml, I don't think the problem you mention exists,
because the query the cursor runs is independently subject to the
parallel restrictions.
> 3. Isn't pg_import_system_collations() unsafe, for the same reason
> as binary_upgrade_create_empty_extension()?
Yes.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e we are seeing a regression with this new approach.
Which changes are you talking about?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t materially increase the chance of a bogus checksum match in
any plausible situation?
2. Does the new logic in pg_rewind to search backward for a checkpoint
work reliably, and will it be slow?
I don't know of a problem in either regard, but I wonder if anyone
else can think of anything.
--
Rober
regression=# set force_parallel_mode to 1;
> SET
> regression=# declare c cursor for select nextval('s1');
> DECLARE CURSOR
> regression=# select cursor_to_xml('c',1,true,true,'');
> ERROR: cannot execute nextval() during a parallel operation
>
> I think this behavior is a bug.
I agree.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Mar 27, 2018 at 7:42 AM, Robert Haas wrote:
> On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila wrote:
>> If we don't want to go with the upperrel logic, then maybe we should
>> consider just merging some of the other changes from my previous patch
>> in 0003* patc
y, and in a case where we previously succeeded.
It's hard for me to believe that this case matters very much. If
you're trying to run pg_rewind on a system where the WAL segments
contain a few zeroed pages, you're probably going to be hosed anyway,
if not by this particular th
On Tue, Mar 27, 2018 at 10:06 PM, Michael Paquier wrote:
> On Tue, Mar 27, 2018 at 02:02:10PM -0400, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Mar 27, 2018 at 11:41 AM, Tom Lane wrote:
>>>> This is ignoring the possibility of damaged data in between, i
elcome further ideas for optimization, but a patch
that makes some cases slightly slower while making others slightly
faster, and also improving the quality of plans in some cases, is not
to my mind an unreasonable thing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise P
> partition-wise join" thread [1]. I haven't done anything about that though.
adt = Abstract Data Type, which I think we've interpreted up until now
to mean an SQL-visible data type, so that seems like an odd choice.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t
> prior checkpoint. In the rare scenario that Tom showed, we should just throw
> an error and fix the patch if it's not doing that already.
It's not clear to me that there is any reasonable fix short of giving
up on this approach altogether. But I might be missing something.
--
Rober
it translated them into a form which is faster to execute, and which
is at least arguably a form of bytecode. It's not going to be clear,
even to an expert, that "compilation of expressions" means something
other than that, but if you say JIT, then all of a sudden people know
wh
gh for government work. He might be
right. But he might also be wrong, because I think Tom is
unquestionably correct when he says that this is weakening the check.
What I'm not sure about is whether it's being weakened enough that
it's actually going to cause problems in practice. Given where we are
in the release cycle, I'd prefer to defer that question to next cycle.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
T since about 1983, and is well-known
under that name, mostly because of Java. Calling it some made-up name
we create ourselves is not going to make this more comprehensible to
users.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
er to say something about casting or converting in the
error message, to give users a clue.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
, really any case where the top scan/join plan would be an Append
node. We're talking about a very small amount of additional planning
time to potentially get a better plan.
I've committed all of these now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
mp;dt=2018-03-30%2002%3A03%3A01
>
> Last file mtime in snapshot: Fri Mar 30 01:25:39 2018 GMT
> ===
> ==6442== Invalid read of size 4
> ==6442==at 0x78D725: apply_scanjoin_target_to_paths (planner.c:6843)
I've committed an at
ncrease the entropy of the
encrypted bytes, but obviously it's not hard to hypothesize cases
where the opposite is true for one reason or another.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
release.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Apr 2, 2018 at 10:52 AM, Peter Eisentraut
wrote:
> On 4/2/18 10:25, Robert Haas wrote:
>> As I understand it on a brief review of the Google search
>> results^W^W^Wliterature, the reason that was done was to prevent
>> things like the CRIME attack, which apparentl
ly-unused bit pattern in the tuple header. The reason I think
this one might be somewhat riskier is because AFAICS it's not so easy
to make sure we've found all the code, even in core, that might care,
as it was in that case; and also because updates happen more than
freezing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
oin and aggregate,
but it does matter now. I'm seeing the planner fail to push down
aggregates in cases that are obvious wins unless I crank up
fdw_tuple_cost.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hat an fsync() failure means you can forget that the write() ever
happened in the first place, but it's hard to imagine an application
that wants that behavior. If the application didn't care about
whether the bytes really got to disk or not, it would not have called
fsync() in the first pl
at we know about, and likely quite a few more that we
> don't.
+1. I didn't understand from Peter's earlier comments that we were
doing that, and I agree that it isn't a good design choice.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ething like that, and then if you try to
change timelines and don't find that record (with the correct previous
TLI), you know something's messed up.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
the OS buffer
cache that can grow and shrink according to memory needs both of other
parts of PostgreSQL and other applications on the system.
> I suppose that if the check-and-clear semantics are problematic for
> Pg, one could suggest a kernel patch that opts-in to a level-triggered
> reporting of fsync() on a per-descriptor basis, which seems to be
> non-intrusive and probably sufficient to cover your expected use-case.
That would certainly be better than nothing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
no way
> that that's all getting fixed by Saturday. Given pretty much everybody's
> unhappiness with the way this patch was forced through at the last minute,
> I do not think you should expect that we'll say, "okay, we'll let you ship
> a bad version of MERGE becau
reate foreign keys cannot that reference them" doesn't make any
sense. I think you mean something like "creating foreign keys that
reference a partitioned table is not supported".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
really have the authority. At the same time, those concerns
didn't generate much discussion and, at least in my case, are not
withdrawn merely because time has passed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
d've been fixed before the patch was
committed. Those things should have been fixed before Simon made a
statement of intention to commit. The things that haven't been fixed
yet should've been fixed then, too. And then the whole thing should
have gone in as one finished, completely-working f
On Fri, Apr 6, 2018 at 4:49 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Wed, Apr 4, 2018 at 1:03 PM, Alvaro Herrera
>> wrote:
>> > Foreign keys on partitioned tables
>> >
>> > Author: Álvaro Herrera
>> > Discussion:
>&
e in full-blown
commit-and-top-speed-and-never-mind-due-deliberation mode?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ill be going into the PostgreSQL 11 release must be
> committed before 2018-04-08 00:00:00 GMT.
Hmm. I just realized that this is a tad ambiguous/surprising. It
looks at like the freeze goes into effect at the *end* of April 7th,
not the beginning.
Am I reading that correctly?
--
Robert Ha
sage said
"must be committed no later than XXX" whereas yours says that the
feature freeze date is XXX.
But no worries - thanks for clarifying.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
at this point to conclude that this
patch, along with MERGE, should be reverted.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
at?
Surely partcache.c is correctly placed next to relcache.c and
syscache.c and everything else in src/backend/utils/cache.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Fri, Apr 6, 2018 at 6:59 PM, Jonathan S. Katz wrote:
> Best of luck to everyone over the next 24hrs!
I think that's the wrong sentiment, honestly. I think we have too
many committers relying way too much on luck already.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb
nt-fix.patch.
Committed. Let me say that you do nice work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ed it. I also investigated it and suggested a fix, which happens
>> to be exactly the fix you've used in the patch.
>
> I didn't mean to detract from that, but I can see how my wording had
> that effect. I apologize.
Committed. Thanks to David for the report and analysis
ut you get as the right
answer, because nobody knows what output a certain built-in hash
function should produce for a given input except by running the code.
If you do the kind of thing shown above, though, then you can easily
see by inspection that you're getting the right answer.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
I don't get this. The executor surely had to (and did) open all of
the relations somewhere even before this patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ded that fsync() doesn't have to do what it says on the tin? I
grant that there doesn't seem to be a better option, but I bet we're
going to have a lot of really unhappy users if we do this.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, Apr 9, 2018 at 2:28 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Sat, Apr 7, 2018 at 5:13 PM, Alvaro Herrera
>> wrote:
>> > I had reservations about a relation_open() in the new executor code. It
>> > seemed a bit odd; we don't have a
On Mon, Apr 9, 2018 at 12:45 PM, Robert Haas wrote:
> Ouch. If a process exits -- say, because the user typed \q into psql
> -- then you're talking about potentially calling fsync() on a really
> large number of file descriptor flushing many gigabytes of data to
> disk. And it
ou things that you
obviously already know, but this doesn't sound like a "near
irresolvable corner case". When the storage goes bonkers, either
PostgreSQL and the kernel can interact in such a way that a checkpoint
can succeed without all of the relevant data getting
sync() them later
-- I spot checked a few places where this code is invoked and in all
of those it looks like the file is already expected to be open.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ls not reported on a per-worker
basis didn't really seem to make sense. Whether that was the right
call is obviously arguable.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e's no patch for this yet
AFAIK, but the fix probably doesn't look that different from
cc5f81366c36b3dd8f02bd9be1cf75b2cc8482bd and could probably use most
of the same infrastructure).
TL;DR: Writing pages (e.g. to set a checksum) doesn't make something
non-parallel-safe. Wri
e details not reported on a per-worker
>> basis didn't really seem to make sense. Whether that was the right
>> call is obviously arguable.
>
> I certainly don't blame you for that.
Thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
der the design of parallel vacuum.
I'm sorry that I didn't get time to work further on this during the
CommitFest. In terms of moving forward, I'd still like to hear what
Andres has to say about the comments I made on March 1st.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
llel
to be false even when final_rel->consider_parallel were true then the
test would be necessary for correctness. That might or might not
happen in the future, so I guess it wouldn't hurt to include this for
future-proofing, but it's not actually a bug fix, so it also wouldn't
h
is to monitor the logs.
Not that log monitoring isn't a good idea, but this is pretty
lightweight.
OTOH, it also seems like this could live as an out-of-core extension,
so I guess if nobody else likes the idea Anastasia could always do it
that way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
x27;s due to some Debian/Ubuntu
policy or just a preference on the part of whoever did the packaging
work. Anyway it's a little hard to argue that the configuration is
insane when we're shipping it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
said that, I'm not averse to providing a solution if it's robust,
> not too invasive and doesn't break other use-cases. So far we've not
> seen a patch that meets those conditions.
Fair enough.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ce may be worth what you paid for it.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t; drop that step. As Peter says, you can usually look in the commit
> log if you care.
The trouble is that sometimes it's not very obvious which commit log
entry relates to which open item.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
it will get rebuilt if, later in the same transaction, they try to
insert data. This whole area needs more research -- there may very
well be good opportunities to reduce lock levels in this area, but it
needs careful study and analysis.
Please revert the part of this commit that changed the
ticularly appealing solution. It would
amount to suppressing a warning that is basically legitimate.
I wonder if there's an easy way to force the libraries that we're
going to need to be loaded before we reach CreateParallelContext().
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
his will delay that process seem better than average.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ated, but if the parent's
tablespace is later changed, the existing children don't move? I
guess that's a defensible behavior, but it's not one I would have
considered. It's certainly quite different from what the TABLESPACE
option means when applied to an unpartitioned t
sert.sql
altogether and have test names that actually mention partitioning.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
. I don't know whether the context is not
needed at all or whether the context is needed but the rationale is
different, but I don't buy that explanation.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
lobalXmin could advance, in between.
>
> What I propose to do to fix the instability is to change the test
> stanza that uses as a key-chosen-at-random to use something less
> far away from the normal range of "C 1" values, so that whether it's
> still visible to get_actual_variable_range has less effect on this
> selectivity estimate. That's a hack, for sure, but I don't see any
> other fix that's much less of a hack.
Thanks for the detective work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
l expect it to have taken
effect. But really, it will take effect at some later time.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ertainly not
going to back-patch a behavior change like that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Apr 12, 2018 at 3:10 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Thu, Apr 12, 2018 at 2:40 PM, Jonathan S. Katz
>> wrote:
>> > If there are no strong objections I am going to add this to the “Older
>> > Bugs”
>> > section of Open Item
ginal cluster TABLESPACE was set on the parent but not on
the children. The children are therefore dumped without a TABLESPACE
clause. On the old cluster that would have worked as intended, but
with this change the children will end up in the parent's tablespace
instead of the da
e sometimes gets us into trouble (see also the
nearby thread on TABLESPACE settings on partitioned tables).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Apr 12, 2018 at 3:59 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> Please revert the part of this commit that changed the lock level.
>
> Done.
Thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ne. There's been a huge amount of progress in
this release: faster pruning, run-time pruning, indexes, foreign keys,
triggers, hash partitioning, default partitioning, update tuple
routing, partition-wise join & aggregate, and other things. What
didn't get done should, in my opi
On Thu, Apr 12, 2018 at 6:01 PM, David Rowley
wrote:
> On 13 April 2018 at 04:57, Robert Haas wrote:
>> BTW, looking at ExecSetupPartitionPruneState:
>>
>> /*
>> * Create a sub memory context which we'll use when making calls to
>> the
>
ly* took effect. If those aren't
the same, it's confusing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Fri, Apr 13, 2018 at 10:50 AM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Wed, Apr 11, 2018 at 8:35 AM, Alvaro Herrera
>> wrote:
>> > Here's an idea. Why don't we move the function/opclass creation lines
>> > to insert.sql, without the
we're hitting
bugs in autoconf that are causing problems, and we can't get them
fixed in the upstream, that's a reason. But switching build systems
won't be frictionless, so I'm not in favor of it unless there's a
clear payoff.
--
Robert Haas
EnterpriseDB: http://ww
On Wed, Apr 18, 2018 at 10:37 AM, Amit Kapila wrote:
> On Fri, Apr 13, 2018 at 10:36 PM, Robert Haas wrote:
>> On Thu, Apr 12, 2018 at 9:29 PM, Michael Paquier wrote:
>>> Still does it matter when the change is effective?
>>
>> I don't really care deeply abou
s by far the bigger issue,
but maybe I'm wrong.
There is really nothing keeping us from removing or reducing the use
of recursive make without switching to cmake. And it's probably not
even that much work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
we stored the executor's memory context in
> PartitionPruneContext and did a context switch back inside
> partkey_datum_from_expr before calling ExecInitExpr.
10% is more than a "slight" improvement, I'd say! It's certainly got
to be worth avoiding the repeated calls to
On Tue, Apr 17, 2018 at 12:57 PM, Tom Lane wrote:
> Now that feature freeze is past, I wonder if it's time to run pgindent.
+1
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
rmed
log entries.
I'm not sure I understand the issue, but I don't like malformed log entries.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
#x27;re describing it as if the JIT just didn't produce
gains sufficient to make up for the cost of doing it, but that's not
really the issue here AFAICS. Here the JIT actually made code that
run slower than the un-JIT-ted code. That seems like a different sort
of problem.
ixed. If that's
what is happening here, it's bound to confuse a lot of people.
Probably you need to add some code to
ExecParallelRetrieveInstrumentation.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ystem that may have non-obvious assumptions about the behavior of
equalTupleDescs(), and I don't think we can have any confidence that
nothing will break unless we do a detailed audit of all that code.
> If we just remove the tdtypeid test, check-world passes.
That does n
at the filesystem will execute
them sequentially anyway, hence the pinch.
I think this is an interesting topic, but I don't plan to work on it
because I have no confidence that I could do it well enough to come
out ahead vs. the status quo.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
would be the use case?
I think stuffing this into pg_class is pretty strange.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
7/1133/ ? I'd be
interested in hearing what happens to performance with that patch
applied.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
will need to install and learn new tools,
buildfarm members will need updating, and there will be some bugs.
None of that is a blocker, but the gains need to outweigh those
disadvantages, and we can't judge whether they do without a clear
explanation of what the gains will be.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Apr 18, 2018 at 9:49 PM, Michael Paquier wrote:
> On Wed, Apr 18, 2018 at 10:52:51AM -0400, Robert Haas wrote:
>> I would just document the risks. If the documentation says that you
>> can't rely on the value until after the next checkpoint, or whatever
>> the r
duce connection
startup latency, although somebody would have to test it to see
whether it really works... a lot of the startup work can't be done
until we know which database the user wants.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ce of
handling all that stuff correctly; an in-core pooler will be able to
do so only with a lot of work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
would benefit, but the cost of
maintaining the new array would be very high in some workloads, so I
don't think you'd come out ahead overall. Feel free to code it up and
test it, though.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
n place and then changing it back before we return seems ugly
and error-prone. I hope we can come up with a solution that doesn't
involve needing to do that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Apr 24, 2018 at 12:21 PM, Robert Haas wrote:
> On Mon, Apr 23, 2018 at 11:25 AM, Alvaro Herrera
> wrote:
>> Robert, I think this is your turf, per 3d956d9562aa. Are you looking
>> into it?
>
> Thanks for the ping. I just had a look over the proposed patch and I
nfo to use the right RT index in
the first place sounds like a better idea than trying to piece
together which RT index we should be using after-the-fact, but I need
to better understand what problems we're trying to fix here before I
can be sure if that's the strategy I want to endorse
801 - 900 of 8046 matches
Mail list logo
