> > Shouldn't we ideally discuss the API first?
>
> I wonder if every GUC that takes an OS command should allow a shared
> object to be specified --- maybe control that if the command string
> starts with a # or something.
>
Very good idea
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
ty-related module, so
users can't see how it is configured, as well as being more
tightly integrated so it can be better tailored to various uses
Summary is that the choice is not random, nor mere preference
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.c
> So it seems to me that you have caught a bug here, and that we had
> better back-patch to v12 so as recovery and pg_resetwal don't mess up
> with AMs using lower values than that.
>
I wonder why is that value 1000, rather than an aligned value or a whole
WAL page?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
On Mon, 12 Aug 2019 at 18:45, Alvaro Herrera
wrote:
> I think that should appease
> Simon's performance concern for the most common case of default
> partition not existing.
>
Much appreciated, thank you.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http:/
On Wed, 7 Aug 2019 at 21:27, Alvaro Herrera
wrote:
> On 2019-Aug-07, Simon Riggs wrote:
>
> > I saw your recent commit and it scares me in various places, noted below.
> >
> > "Commit: Apply constraint exclusion more generally in partitioning"
> >
>
lease could we do perf checks, with tests up to 1000s of partitions? And
if there is a regression, I would vote to revoke this patch or address the
request in a less general way.
Hopefully I have misunderstood and/or there is no regression.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
p the one
> in XLOG_HEAP2_MULTI_INSERT.
>
Fix proposed by Petr, with comments as explained by Andres.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
allow_XLOG_HEAP2_NEW_CID_while_building_snapshot.v1.patch
Description: Binary data
o parts = 0.071 ms
> # 1 hash = 0.071 ms (did someone optimize this case?!)
> # 2 hash ~ 0.126 ms (+ 0.055 ms)
> # 50 hash ~ 0.155 ms
> # 100 hash ~ 0.178 ms
> # 150 hash ~ 0.232 ms
> # 200 hash ~ 0.279 ms
> # overhead ~ (0.050 + [0.0005-0.0008] *
On Mon, 24 Jun 2019 at 18:01, James Coleman wrote:
> On Mon, Jun 24, 2019 at 12:56 PM Simon Riggs
> wrote:
>
> > What is the specific use case for this? This sounds quite general case.
>
> They are both general cases in some sense, but the concerns lie mostly
> with w
is sounds quite general case.
Do we know something about the nearly-sorted rows that could help us? Or
could we introduce some information elsewhere that would help with the sort?
Could we for-example, pre-sort the rows block by block, or filter out the
rows that are clearly out of order, so we can
as very expensive for large sorts.
It's no real problem if incremental sorts don't support backwards scans -
we just won't use incremental in that case.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
ink hacking the join condition to
> add an OR .. IS NULL is a bad idea. I guess you're not deterred by
> that?
>
Surely we want both?
1. Transform when we can
2. Else apply some other approach if the cost can be reduced by doing it
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Solutions for the Enterprise
ted in
> that transaction, use) etc the temp table after the PREPARE.
>
I don't see there is a problem here, but run out of time to explain more,
for a week.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, 24 May 2019 at 01:39, Michael Paquier wrote:
> On Thu, May 23, 2019 at 08:54:59AM -0700, Andres Freund wrote:
> > On 2019-05-23 12:36:09 +0100, Simon Riggs wrote:
> >> The ONLY case where this matters is if someone does a PREPARE and then
> >> starts doin
On Thu, 23 May 2019 at 16:55, Andres Freund wrote:
> Hi,
>
> On 2019-05-23 12:36:09 +0100, Simon Riggs wrote:
> > The ONLY case where this matters is if someone does a PREPARE and then
> > starts doing other work on the session. Which makes no sense in the
> normal
> &
work on the session until COMMIT/ABORT. That means we can then
drop locks on sesion temporary tables and drop on-commit temp tables when
we hit the prepare, not try and hold them for later.
A patch is needed to implement the above, but I think we can forget the
current patch as not needed.
--
Si
o I suggest we do
the same on XLogBackgroundFlush() so callers can indicate whether they want
it to be flexible or not.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, 24 Apr 2019 at 12:55, Etsuro Fujita
wrote:
> > My point is that this should not be necessary.
>
> In my opinion, I think this is necessary...
>
Could we decide by looking at what FDWs are known to exist? I hope we are
trying to avoid breakage in the smallest number of F
to search for data with historic snapshots.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, 29 Mar 2019 at 16:32, Andres Freund wrote:
> On 2019-03-29 16:20:54 +0000, Simon Riggs wrote:
> > On Fri, 29 Mar 2019 at 16:12, Andres Freund wrote:
> >
> >
> > > On 2019-03-29 15:58:14 +, Simon Riggs wrote:
> > > > On Fri, 29
On Fri, 29 Mar 2019 at 16:12, Andres Freund wrote:
> On 2019-03-29 15:58:14 +0000, Simon Riggs wrote:
> > On Fri, 29 Mar 2019 at 15:29, Andres Freund wrote:
> > > That's far from a trivial feature imo. It seems quite possible that
> we'd
> > > end
On Fri, 29 Mar 2019 at 15:29, Andres Freund wrote:
> On 2019-03-29 09:37:11 +0000, Simon Riggs wrote:
>
> > While trying to understand this, I see there is an even better way to
> > optimize this. Since we are removing dead index tuples, we could alter
> the
> > k
On Fri, 29 Mar 2019 at 09:51, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-03-28 18:16, Simon Riggs wrote:
> > SET TABLESPACE should not recurse because it copies the data, while
> > holding long locks. If that was ever fixed so it happened concurrent
ne less heap fetch we
need to perform when we delete the page - it's possible we optimize that
away completely by doing this.
Since this point of the code is clearly going to be a performance issue it
seems like something we should do now.
--
Simon Riggshttp://www.2ndQuadrant
could recurse by default.
IMHO this should be renamed to ALTER TABLE ... MOVE TO TABLESPACE, so its
actual effect is clearer.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
o the region administrator, down to the city administrators.
>
That use case is possible using different privileges.
Having different owners makes it *very* difficult to administer.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Dev
On Thu, 28 Mar 2019 at 15:39, Alvaro Herrera
wrote:
> On 2019-Mar-28, Simon Riggs wrote:
>
> > On Thu, 28 Mar 2019 at 14:56, Alvaro Herrera
> > wrote:
> >
> > > I have not reinstated phase numbers; I have Rahila's positive vote for
> > > them. Do
preference, then I say we should have numbers.
Numbering is natural for people. If we say "It's currently doing phase
XYZ", they will say "Is that the 3rd phase?", we'll say "No, actually the
5th", and then they will say "Why didn't you just num
On Sun, 24 Mar 2019 at 13:02, Amit Kapila wrote:
> On Sat, Mar 23, 2019 at 4:33 AM FabrÃzio de Royes Mello
> wrote:
> >
> > On Fri, Mar 22, 2019 at 2:25 PM Simon Riggs
> wrote:
> > >
> > > As noted by a PostgreSQL user to me, error messages for NOT NULL
&
is easy to fix once/if we agree
to change.
Thanks
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
rationalize_constraint_error_messages.v1.patch
Description: Binary data
On Fri, 22 Mar 2019 at 11:39, Tom Lane wrote:
> Simon Riggs writes:
> > I agree that the issue of mixing sorts at various points will make
> nonsense
> > of the startup cost/total cost results.
>
> Right.
>
> > I don't see LIMIT costing being broken as a re
s exactly right. But ISTM that LIMIT itself is
the issue there and it need more smarts to correctly calculate costs.
I don't see LIMIT costing being broken as a reason to restrict this
optimization. I would ask that we allow improvements to the important use
case of ORDER BY/LIMIT, then spend time on making LIMIT work correctly.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, 21 Mar 2019 at 15:18, Alexander Korotkov
wrote:
> On Thu, Mar 21, 2019 at 9:26 PM Simon Riggs wrote:
>
>
> > It's been pointed out to me that 52ac6cd2d0cd70e01291e0ac4ee6d068b69bc478
> > introduced a WAL incompatibility that has not been flagged.
> >
&
by code at
52ac6cd2d0cd70e01291e0ac4ee6d068b69bc478 or later then we will have
problems, since deleteXid will not be set correctly.
It seems this should not have been backpatched.
Please give your assessment.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, 26 Feb 2019 at 17:38, Andres Freund wrote:
> Hi,
>
> On 2019-02-26 12:57:14 +0000, Simon Riggs wrote:
> > On Tue, 26 Feb 2019 at 12:19, Fabien COELHO wrote:
> > I've put it as 256 args now.
> >
> > The overhead of that is about 2kB, so not really
for such a facility, so instead I think
> ATColumnChangeRequiresRewrite() should have a hard-wired call for
> F_TIMESTAMPTZ_TIMESTAMP and F_TIMESTAMP_TIMESTAMPTZ. Patch attached. If
> we
> find more applications of this concept, it shouldn't be hard to migrate
> this
> logic into SupportRequestSimplify. Does anyone think that's better to do
> from
> the start?
>
Looks good, would need docs.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, 21 Feb 2019 at 15:38, Kuntal Ghosh
wrote:
> Thank you for the patch. It seems to me that while performing COPY
> FREEZE, if we've copied tuples in a previously emptied page
There won't be any previously emptied pages because of the pre-conditions
required for FREEZE.
omewhere? There is no limit discussed in the
> PREPARE documentation, I tested up to 20. I'd sugggest to add something at
> the end of the paragraph about variable substitution in the "Custom
> Script" section, eg "A maximum of XX variable references can appe
the error message when you hit
the limit. The highest argument id is MAX_ARGS - 1, but the max number of
arguments is MAX_ARGS.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
e largest footgun in Postgres, given that
command's current behavior and the size of partitioned tables.
If it moved partitions concurrently I'd feel differently.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Review comments != holding
hostages.
If we add one set of code now and need to add another different one later,
we will have 2 sets of code that do similar things.
I'm surprised to hear you think that is a good thing.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ing it for legacy inheritance, but if the majority is to change it
> for both, let's do that.
>
-1 for changing legacy inheritance. Two separate features. Inheritance has
been around for many years and its feature set is stable. No need to touch
it.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, 19 Feb 2019 at 23:09, Paul Ramsey wrote:
> On Sat, Feb 16, 2019 at 7:25 AM Simon Riggs wrote:
>
> > Could we get an similarly optimized implementation of -> operator for
> JSONB as well?
> > Are there any other potential uses? Best to fix em all up at once and
tables. For that case, it seems like reset hashtable is too much.
Can we use our knowledge of the structure of locks, i.e. partition locks
are all children of the partitioned table, to do a better job?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
good.
Could we get an similarly optimized implementation of -> operator for JSONB
as well?
Are there any other potential uses? Best to fix em all up at once and then
move on to other things. Thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Po
On Wed, 13 Feb 2019 at 00:46, Alvaro Herrera
wrote:
> Here's a sample
> concurrent index build on a 100M tuple table.
Cool
> There are no concurrent
> transactions, so phases that wait for lockers don't appear.
Would prefer to see them, so we know they are
On Tue, 29 Jan 2019 at 09:55, Tom Lane wrote:
> Simon Riggs writes:
> > On Sun, 27 Jan 2019 at 19:17, Tom Lane wrote:
> >> ... I don't
> >> know whether that would satisfy your concern, because I'm not clear
> >> on what your concern is.
>
>
se I'm not clear
> on what your concern is.
>
To be able to extract indexable clauses where none existed before.
Hash functions assume that x = N => hash(x) = hash(N) AND x = N
so I want to be able to assume
x = K => f(x) = f(K) AND x = K
for specific f()
to allow indexable operation
might need to adjust in the future
> during a detach will be changes that require AccessExclusiveLock
> either, but that sounds awfully risky to me. We have very little DDL
> that runs with less than AccessExclusiveLock, and I've already found
> lots of subtle problems that have to be patched up just for the
> particular case of allowing attach/detach to take a lesser lock on the
> parent table, and I bet that there are a whole bunch more similar
> problems when you start talking about weakening the lock on the child
> table, and I'm not convinced that there are any reasonable solutions
> to some of those problems, let alone that we can come up with good
> solutions to all of them in the very near future.
>
I've not read every argument on this thread, but many of the later points
made here are spurious, by which I mean they sound like they could apply
but in fact do not.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
number of output rows, in cases
where that is variable and dependent upon the input params?
* Allow a normal term to match a functional index, e.g. WHERE x =
'abcdefgh' => WHERE substr(x, 1 , 5) = 'abcde' AND x = 'abcdefgh'
* Allow us to realise that ORDER BY f(
this is now in good shape, let me
> > know if you think anything else needs to be done.
>
> Lotta work for a one-line code change, eh? Pushed now.
>
Good decision, thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL
e approach used
here is better than that and doesn't rely on string handling at all.
Most importantly, it works.
BUT if there really is something wrong, Pavan would love to know and is
willing to make any changes suggested. Review requested.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
rized scans (for
> nestloop-with-inner-fetch-by-tid) and hash join, because each of those
> can dominate depending on how many tuples you're joining.
>
That would certainly help if you are building a column store, or other new
index types.
--
Simon Riggshtt
ing to solve the same problem. If so, this is
the best solution.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
finity'::timestamp = 'infinity'::timestamp;
?column?
--
t
so I was thinking that
postgres=# select 'infinity'::timestamp - 'infinity'::timestamp;
would be zero rather than an error, for least surprise.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
another datatype that is
stripped down for performance. I understand and agree with that need.
But the current datatypes do handle much complexity already. Blocking this
proposal would not change that, IMHO. All that is being proposed is a small
change to rationalize the existing code.
--
Si
At present we have a timestamp of 'infinity' and infinite ranges, but no
infinite interval
SELECT 'infinity'::timestamp;
works
SELECT 'infinity'::interval;
ERROR: invalid input syntax for type interval: "infinity"
Seems a strange anomaly that we should f
Add new table-level option for row_visibility and
row_visibility_retention_interval
2. Add option to heap_beginscan
3. Add option handling in heap prune
4. Add option to tqual
Thoughts?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
n would be
important.
It does seem likely that the new scheme will require us to look carefully
at when parameters are reloaded, since the timing of reloads was never
taken into account in the previous coding.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.c
On Mon, 10 Dec 2018 at 16:52, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 10 Dec 2018 at 16:32, Tom Lane wrote:
> >> We were just busy shooting down a different suggestion of
> >> behavior-changing GUCs. A GUC that turns all ALTERs into no-ops
> >&
On Mon, 10 Dec 2018 at 16:32, Tom Lane wrote:
> Simon Riggs writes:
> > I suggest ALTER TABLE should respond to a parameter setting of
> ddl_dry_run
> > = on, so the whole world doesn't need to rewrite its syntax to support
> the
> > new option.
>
> We we
ose routines.)
>
You need to take a table lock to find out things about the table.
EXPLAIN seems like the wrong place for this.
I suggest ALTER TABLE should respond to a parameter setting of ddl_dry_run
= on, so the whole world doesn't need to rewrite its syntax to support the
new op
On Fri, 30 Nov 2018 at 23:08, Michael Paquier wrote:
> On Fri, Nov 30, 2018 at 02:55:47PM +0000, Simon Riggs wrote:
> > 1df21ddb looks OK to me and was simple enough to backpatch safely.
>
> Thanks for the feedback!
>
> > Seems excessive to say that the WAL record is c
hould
backpatch this change, assuming it is acceptable.
This patch doesn't do it, but the suggestion that we touch
GetSnapshotData() in the same way so we de-duplicate eagerly is a different
matter and would need careful performance testing to ensure we don't slow
down 2PC users.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> all of the other 3rd party backup solutions and any restore solution
> that a user has come up with, are going to have to be changed to deal
> with the changes in how recovery works, so this is a good time to make
> these changes.
>
If those tools are updated and the changes all
pportunity to make improvements on
> the backup side as well.
>
> I'll submit a patch for the 2019-01 commitfest.
>
-1 for removal, in this release
It's not there because anyone likes it, it's there because removing it is a
risk
Recent changes are the reason to keep it,
aving indexes defined using WHERE NOT NULL is a very important use case.
> Assuming we go that route, I'd propose we still yank the existing todo
> comment about turning it into a GUC.
>
Agreed
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
der locale issues etc.), so
> we need to recompute the generated columns on the target anyway, so it's
> pointless to send the already computed stored values.
>
Makes sense.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, 6 Nov 2018 at 11:06, Robert Haas wrote:
> On Tue, Nov 6, 2018 at 2:01 PM Simon Riggs wrote:
> > If you can remove the ERROR without any other adverse effects, that
> sounds great.
> >
> > Please let us know what, if any, adverse effects would be caused so
On Tue, 6 Nov 2018 at 10:56, Robert Haas wrote:
> On Tue, Nov 6, 2018 at 1:54 PM Simon Riggs wrote:
> > Error in the COPY or in the DDL? COPY preferred. Somebody with insert
> rights shouldn't be able to prevent a table-owner level action. People
> normally drop partitions
uery shouldn't make other cases more difficult from a
behavioral perspective just to avoid the ERROR. The ERROR sounds annoying,
but not sure how annoying avoiding it would be.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ored generated columns should be treated just like we'd treat a column
value added by a trigger.
e.g. if we had a Timestamp column called LastUpdateTimestamp we would want
to send that value
> Similar considerations also apply to foreign tables. What is the
> meaning of a stored generated
On Wed, 31 Oct 2018 at 08:29, Erik Rijkers wrote:
> On 2018-10-31 09:15, Simon Riggs wrote:
> > On Wed, 31 Oct 2018 at 07:58, Erikjan Rijkers wrote:
> >
> >
> >> I have also noticed that logical replication isn't possible on tables
> >> with a gen
hould be to just treat them as a value.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
r due to ordering being required from the return value of some
> precision loss function.
>
Anything left anchored would benefit, so SUBSTR(), TRIM() etc
Main use for this would be where the partition condition is a function, so
we can still order by partitions easily.
--
Simon Riggs
ers ended up.
Presumably stored values can just be read from storage, so no overhead in
after triggers?
Having the stored values show as NULL would be OK for virtual ones. But
what do we do if the column is NOT NULL? Do we still have nulls then?
It would be useful to have a way to generate
ld hit limits and that would naturally prune the
workload before it hit the standby.
It's hard to see how any reasonable workload would affect the standby. And
if it did, you'd change the parameter and restart, just like you already
have to do if someone changes max_connections on master first.
So I don't see any problem or anything abnormal in what Tom suggests.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
le.
>
> Wouldn't that take down the entire cluster with no restart?
>
Please explain why you think that would be with no restart.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
l tested, or even testable.
>
I've never seen an out of memory on the lock table and that seems even less
likely since changes in 9.2.
So no problem removing that.
Are you looking for a patch to backpatch, or just a change for the future?
Changing the parameter in a backpatch seems mo
e a column.
Alternatively, include only the heap block number. That would make it
non-unique, but never more than 240 duplicates. So it would allow suffix
truncation, and yet still avoid the multi-page split effect.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquad
e.g. partitioning contents afaics.
I think you may be right in the general case, but ISTM possible to
invalidate/refresh just the list of partitions.
If so, that idea would seem to require some new, as-yet not invented mechanism.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
those cases out.
If we trust pg_wal over the archive, you still need to solve the
problem of what happens if pg_wal is behind the archive, so when you
hit end of pg_wal you would need to trap that error and flip back to
requesting any missing files, including the existing WAL file, from
the a
On 1 August 2018 at 23:11, Alvaro Herrera wrote:
> On 2018-Aug-01, Dave Cramer wrote:
>
>> See attached patch which fixes it, and adds a test for it.
>
> Pushed, thanks.
Thanks
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Re
repare
> a patch. The company, I am currently working for, is also interested
> in sponsoring a support company to fix this problem.
Seems like a new option to choose your preference would help here,
with the default being the existing behavior.
Suggestions for parameter na
huge performance benefit.
>
> So, I'm going to commit this, if no objections.
+1 to commit.
What will the commit message be?
For me, this is about reducing contention on index leaf page hotspots,
while at the same time reducing the path length of lock acquisition on
leaf pages
--
Simon Rig
onger any need to consider this.
Works for me!
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 13 July 2018 at 03:14, Imai, Yoshikazu wrote:
> On Mon, July 9, 2018 at 5:25 PM, Simon Riggs wrote:
>> Please can you check insertion with the index on 2 keys
>> 1st key has 10,000 values
>> 2nd key has monotonically increasing value from last 1st key value
>>
>&
LIST partitions are less likely to have a clear pattern, so I would
treat them like HASH and assume the data is not sorted by partition.
So for this patch, just add an "if (RANGE)" test.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
graph, then only one backend should
attempt this at a time. We should keep track of reorder-requests, so
if two backends arrive at the same conclusion then only one should
proceed to do this.
Many deadlocks happen between locks in same table. It would also be a
useful optimization to check ju
ndex.
I hope we can see a patch that just adds the sorting-by-TID property
so we can evaluate that aspect before we try to add other more
advanced index ideas.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 17 July 2018 at 19:47, Robert Haas wrote:
> On Mon, Jul 9, 2018 at 6:00 AM, Simon Riggs wrote:
>> Proposal would be to add a new lock mode "ShareUpdate", which does not
>> conflict with itself and yet conflicts with "ShareUpdateExclusive" or
>> highe
key (id, logdate));
# script_ordered2.sql
\set i random(1, 1)
INSERT INTO ordered2 (id, value) VALUES (:i, 'abcdefghijklmnoprsqtuvwxyz');
Thanks
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
much overhead it's
>> eating into our margin, nor that the generated code SIGILLs on such
>> platforms.
>
>
> Yeah.
>
> I'll mark this as "returned with feedback" in the commitfest. The way
> forward is to test if we can get the same performance
acking away from the main idea.
Implementation would be to introduce the new infrastructure, then make
it work for the VACUUM/CREATE INDEX CONCURRENTLY case, then work
through other commands one by one.
Thoughts?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
se an XLOG_RUNNING_XACTS
> record is replayed?
Locks held by subtransactions were not released at the correct timing
of top-level commit; they are now.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
d,
> and register the information of all the tablespace into it. Then, WAL replay
> of XLOG_DBASE_DROP record scans shared_buffers once and deletes
> all tablespaces. POC patch is attached.
Seems clear on read of patch, but not tested it.
Please replace tablespace_num with ntable
We probably need to be able to identify code that
will/will not work in the new mode.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
we shouldn't consider
>> backpatching this.
>
> I guess you could go either way ... we're just changing one unhelpful
> error with a better one: there is no change in behavior. I would
> backpatch this, myself, and avoid the code divergence.
WAL control functions all
should be fixed separately.
Since Greg has not reappeared to speak either way, I agree we should
revert, though I will add comments to document this. I will do this
today.
Looks like we would need a multi-node isolation tester to formally
test the AEL lock release, so I won't add tests
ure, it might happen that we didn't manage to exclusively lock leaf in
> this
> way when _bt_getroot() points us to leaf page. But this case could be handled
> in _bt_search() by relock. Please, find implementation of this approach in
> the
> attached patch.
It's a good idea.
401 - 500 of 716 matches
Mail list logo
