Hello Daniel,
I want to measure TPS at a particular connection count. [...]
pgbench's "including connections establishing" number is polluted by
fact that for many seconds the benchmark is running with less than the
expected number of connections. I thought that was why the 'excluding'
Hello Shawn, Alvaro,
Thank you for testing patches and comments.
Yes, there are two patches:
(1) v4_default_partition_pruning.patch fixes problems with default
partition pruning
and (2) v3_ignore_contradictory_where_clauses_at_partprune_step.patch determines
if a given clause contradicts a
On Fri, Jun 21, 2019 at 1:21 AM Thomas Munro wrote:
> I ran into someone with a system where big queries scanning 8GB+ of
> all-in-cache data took consistently ~2.5x longer on a primary server
> than on a replica. Both servers had concurrent activity on them but
> plenty of spare capacity and
On Mon, Jun 24, 2019 at 11:10:54PM +0300, Alexander Lakhin wrote:
> When running on REL_11_STABLE the following query:
> CREATE PROCEDURE test_ambiguous_procname(int) as $$ begin end; $$
> language plpgsql;
> CREATE PROCEDURE test_ambiguous_procname(text) as $$ begin end; $$
> language plpgsql;
>
Short benchmark runs are bad if the runs aren't long enough to produce
consistent results.
Having to do long runs because a benchmarking tool 'converges to reality' over
time in reporting a tps number, due to miscalculation, is also bad.
I want to measure TPS at a particular connection count.
> In particular, in order to consider it unexpected, you have to suppose
>> that the content rules for postgresql.auto.conf are different from those
>> for postgresql.conf (wherein we clearly allow last-one-wins). Can you
>> point to any user-facing documentation that says that?
>
> The backend
On 6/25/19 4:06 AM, Alvaro Herrera wrote:
> On 2019-Jun-24, Robert Haas wrote:
>
>> On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
>>> All that said, whatever code it is that we write for pg_basebackup to
>>> do this properly should go into our client side library, so other tools
>>> can
On Mon, Jun 24, 2019 at 11:47:09AM +0200, Dent John wrote:
> I’ll see if I can get the patch applied and feed back on how much it
> move towards making my use case a viable proposition.
There is another patch which provides more coverage for reloptions:
https://commitfest.postgresql.org/23/2064/
On Mon, Jun 24, 2019 at 11:27:26PM +0200, Peter Eisentraut wrote:
> Yeah but the new code already rejects those anyway. Note how
> timestamptz_in() has explicit switch cases to accept those, and we
> didn't carry those over into check_recovery_time().
Ditto. I was not paying much attention to
On Mon, Jun 24, 2019 at 04:51:04PM -0700, Noah Misch wrote:
> On Mon, Jun 24, 2019 at 08:52:00AM -0400, Alvaro Herrera wrote:
>> On 2019-Jun-24, Michael Paquier wrote:
>>> Alvaro, did 313f56ce fix all the issues related to this thread?
>>
>> Yes, as far as I am aware it does.
>
> I agree, it
On Sun, Jun 23, 2019 at 10:29:25PM +0900, Michael Paquier wrote:
> So, are there any objections with this patch? Or do people think that
> it's too late for v12 and that it is better to wait until v13 opens
> for business?
Committed, and open item closed.
--
Michael
signature.asc
Description:
On Mon, Jun 24, 2019 at 08:52:00AM -0400, Alvaro Herrera wrote:
> On 2019-Jun-24, Michael Paquier wrote:
> > On Fri, Jun 14, 2019 at 06:31:52PM -0400, Alvaro Herrera wrote:
> > > BTW I tested this manually and it seemed to work as intended, ie., if I
> > > change /etc/hosts for the hostname I am
On Mon, Jun 24, 2019 at 4:16 PM Tomas Vondra
wrote:
>
> On Mon, Jun 24, 2019 at 01:00:50PM -0400, James Coleman wrote:
> >On Mon, Jun 24, 2019 at 12:56 PM Simon Riggs wrote:
> >>
> >> On Mon, 24 Jun 2019 at 16:10, James Coleman wrote:
> >>>
> >>> On Thu, Jun 13, 2019 at 11:38:12PM -0400, James
On 2019-06-24 06:06, Michael Paquier wrote:
> - if (strcmp(*newval, "epoch") == 0 ||
> - strcmp(*newval, "infinity") == 0 ||
> - strcmp(*newval, "-infinity") == 0 ||
> Why do you remove these? They should still be rejected because they
> make no sense as recovery
On 2019-06-19 22:34, Peter Eisentraut wrote:
> src/include/common/unicode_norm_table.h also should be updated to the
> latest Unicode tables, as described in src/common/unicode. See attached
> patches. This also passes the tests described in
> src/common/unicode/README. (That is, the old code
On 2019-06-19 21:55, Tom Lane wrote:
> Peter Eisentraut writes:
>>> Indeed. Here is an updated script and patch.
>
>> committed (to master)
>
> Cool, but should we also put your recalculation script into git, to help
> the next time we decide that we need to update this list? It's
>
On Mon, Jun 24, 2019 at 07:05:24PM +0100, Simon Riggs wrote:
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
On Mon, Jun 24, 2019 at 01:00:50PM -0400, James Coleman wrote:
On Mon, Jun 24, 2019 at 12:56 PM Simon Riggs wrote:
On Mon, 24 Jun 2019 at 16:10, James Coleman wrote:
On Thu, Jun 13, 2019 at 11:38:12PM -0400, James Coleman wrote:
>I think the first thing to do is get some concrete numbers
Hello hackers,
When running on REL_11_STABLE the following query:
CREATE PROCEDURE test_ambiguous_procname(int) as $$ begin end; $$
language plpgsql;
CREATE PROCEDURE test_ambiguous_procname(text) as $$ begin end; $$
language plpgsql;
DROP PROCEDURE test_ambiguous_procname;
under valgrind I get
Greetings,
* Sascha Kuhl (yogidaba...@gmail.com) wrote:
> Does Microsoft or any other DB manufacturer have an ear on this mailing
> list?
Many, many, many of the people who are on this mailing list work for DB
manufacturers.
I suspect that most of them are manufacturing PostgreSQL.
Thanks,
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Stephen and Magnus want a warning, because it's an indication that a
> > tool author, or *something* modified the file in an unexpected way, and
> > that we are having to do some kind of cleanup on the file because of
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2019-Jun-24, Robert Haas wrote:
>
> > On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> > > All that said, whatever code it is that we write for pg_basebackup to do
> > > this properly should go into our client side
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> >> Ah, got it. So it seems like the correct behavior might be for
> >> ALTER SYSTEM to
> >> (a) run through the whole file and remove any conflicting lines;
> >> (b)
Stephen Frost writes:
> Stephen and Magnus want a warning, because it's an indication that a
> tool author, or *something* modified the file in an unexpected way, and
> that we are having to do some kind of cleanup on the file because of it.
But you're presuming something that not everybody
On 2019-Jun-24, Robert Haas wrote:
> On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> > All that said, whatever code it is that we write for pg_basebackup to do
> > this properly should go into our client side library, so other tools can
> > leverage that and avoid having to write it
On 2019-Jun-23, Sascha Kuhl wrote:
> Does Microsoft or any other DB manufacturer have an ear on this mailing
> list?
This is a public mailing list, so anybody with an interest can subscribe
to it. If you search the archives, you might find a more explicit
answer to your question.
--
Álvaro
Does Microsoft or any other DB manufacturer have an ear on this mailing
list?
Sascha Kuhl
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> > All that said, whatever code it is that we write for pg_basebackup to do
> > this properly should go into our client side library, so other tools can
> > leverage that and avoid having to
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> > Ah, got it. So it seems like the correct behavior might be for
> > ALTER SYSTEM to
> > (a) run through the whole file and remove any conflicting lines;
> > (b) append new setting at
Robert Haas writes:
> On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
>> Ah, got it. So it seems like the correct behavior might be for
>> ALTER SYSTEM to
>> (a) run through the whole file and remove any conflicting lines;
>> (b) append new setting at the end.
> That is exactly the behavior
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jun 21, 2019 at 11:24 AM Stephen Frost wrote:
> > That's not quite accurate, given that it isn't how the ALTER SYSTEM call
> > itself works, and clearly isn't how the authors of that feature expected
> > things to work or they
On Thu, 20 Jun 2019 at 00:31, Andres Freund wrote:
>
> > > Or else, do you think we can just increment the record pointer by
> > > doing something like (lastReplayedEndRecPtr % XLOG_BLCKSZ) +
> > > SizeOfXLogShortPHD() ?
> >
> > I found out that we can't do this, because we don't know whether the
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 what happens when they're
Hi,
On 2019-06-24 10:41:06 -0700, Ashwin Agrawal wrote:
> Proposing following changes to make predicate locking and checking
> functions generic and remove dependency on HeapTuple and Heap AM. We
> made these changes to help with Zedstore. I think the changes should
> help Zheap and other AMs in
On Mon, Jun 3, 2019 at 5:24 PM Ashwin Agrawal wrote:
> There were few more minor typos I had collected for table am, passing them
> along here.
>
> Some of the required callback functions are missing Assert checking (minor
> thing), adding them in separate patch.
>
Curious to know if need to
On 2019-Jun-22, Alexander Korotkov wrote:
> 2. Also introduce FullMultixactId, and apply to MultixactId the
> similar change as #1.
> 3. Change SLRU on-disk format to handle 64-bit xids and multixacts.
> In particular make SLRU page numbers 64-bit too. Add SLRU upgrade
> procedure to pg_upgrade.
Proposing following changes to make predicate locking and checking
functions generic and remove dependency on HeapTuple and Heap AM. We
made these changes to help with Zedstore. I think the changes should
help Zheap and other AMs in general.
- Change PredicateLockTuple() to PredicateLockTID().
On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> All that said, whatever code it is that we write for pg_basebackup to do this
> properly should go into our client side library, so other tools can leverage
> that and avoid having to write it themselves.
That is probably only going to
On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> Ah, got it. So it seems like the correct behavior might be for
> ALTER SYSTEM to
> (a) run through the whole file and remove any conflicting lines;
> (b) append new setting at the end.
That is exactly the behavior for which I am arguing.
On Fri, Jun 21, 2019 at 11:24 AM Stephen Frost wrote:
> That's not quite accurate, given that it isn't how the ALTER SYSTEM call
> itself works, and clearly isn't how the authors of that feature expected
> things to work or they would have actually made it work. They didn't,
> and it doesn't
On Mon, Jun 24, 2019 at 12:56 PM Simon Riggs wrote:
>
> On Mon, 24 Jun 2019 at 16:10, James Coleman wrote:
>>
>> On Thu, Jun 13, 2019 at 11:38:12PM -0400, James Coleman wrote:
>> >I think the first thing to do is get some concrete numbers on performance
>> >if we:
>> >
>> >1. Only sort one
On Mon, 24 Jun 2019 at 16:10, James Coleman wrote:
> On Thu, Jun 13, 2019 at 11:38:12PM -0400, James Coleman wrote:
> >I think the first thing to do is get some concrete numbers on performance
> if we:
> >
> >1. Only sort one group at a time.
> >2. Update the costing to prefer traditional sort
On Wed, 5 Jun 2019 at 17:14, Rafia Sabih wrote:
> Regarding this, I came across this,
> /*
> * Incremental sort can't be used with either EXEC_FLAG_REWIND,
> * EXEC_FLAG_BACKWARD or EXEC_FLAG_MARK, because we hold only current
> * bucket in tuplesortstate.
> */
> I think that is quite
I wrote:
> > I'll look for other rules that could be more
> > easily optimized, but I'm not terribly optimistic.
>
> I found a possible other way to bring the size of the transition table
> under 32k entries while keeping the existing no-backup rules in place:
> Replace the "quotecontinue" rule
On 2019-06-20 18:33, Andres Freund wrote:
> I wonder if we need to split the timeout into two: One value for
> postmaster to acknowledge the action, one for that action to
> complete. It seems to me that that'd be useful for all of starting,
> restarting and stopping.
>
> I think we have all the
Thomas Munro writes:
> Hmm. I wonder if we should rename force_parallel_mode to
> force_gather_node in v13. The current name has always seemed slightly
> misleading to me; it sounds like some kind of turbo boost button but
> really it's a developer-only test mode. Also, does it belong under
>
Hi,
On June 24, 2019 8:19:13 AM PDT, Robert Haas wrote:
>On Fri, Jun 21, 2019 at 7:01 PM Alexander Korotkov
> wrote:
>> On Thu, Mar 28, 2019 at 8:30 AM Thomas Munro
>wrote:
>> > Thanks for the reviews! Pushed.
>>
>> Any ideas we should move towards 64-bit xids in more places? That
>has
>>
On Mon, Jun 24, 2019 at 11:21 AM Tom Lane wrote:
> > I'm repeating myself, but I still think it's super-useful to
> > distinguish things which are "for expert use only" from things which
> > are "totally bonkers."
>
> Agreed, although "DML vs DDL" is a pretty poor approximation of that
>
Robert Haas writes:
> On Fri, Jun 21, 2019 at 4:37 PM Tom Lane wrote:
>> This line of thought leads to the conclusion that we do want
>> separate "allow_system_table_dml" and "allow_system_table_ddl"
>> bools. Otherwise, the backwards-compatibility hack would need
>> to turn on a level of
On Fri, Jun 21, 2019 at 7:01 PM Alexander Korotkov
wrote:
> On Thu, Mar 28, 2019 at 8:30 AM Thomas Munro wrote:
> > Thanks for the reviews! Pushed.
>
> Any ideas we should move towards 64-bit xids in more places? That has
> been discussed several times already. I think last time it was
>
On Thu, Jun 13, 2019 at 11:38:12PM -0400, James Coleman wrote:
>I think the first thing to do is get some concrete numbers on performance if
>we:
>
>1. Only sort one group at a time.
>2. Update the costing to prefer traditional sort unless we have very
>high confidence we'll win with incremental
On Fri, Jun 21, 2019 at 3:45 AM RekGRpth wrote:
> >It is not plpgsql's job to clean up after other backend subsystems
> during a transaction abort.
> But plpgsql do clean up on success! I suggest only do cleanup and on
> exception.
Except that's wrong, because when an error happens, cleanup is
Thomas Munro writes:
> In commit a76200de we added a line to unset MAKELEVEL to fix a problem
> with our temp-install logic. I don't think it was a great idea to
> clear MAKEFLAGS at the same time, because now when you type "make -s
> -j8" on a non-GNU system it ignores you and is loud and slow.
On Fri, Jun 21, 2019 at 6:54 PM Tom Lane wrote:
> > That's not a bad goal, although invoking a user-supplied callback
> > while holding a buffer lock is a little scary.
>
> I nominate Robert for Understater of the Year. I think there's pretty
> much 0 chance of that working reliably.
It's an
On Fri, Jun 21, 2019 at 4:37 PM Tom Lane wrote:
> This line of thought leads to the conclusion that we do want
> separate "allow_system_table_dml" and "allow_system_table_ddl"
> bools. Otherwise, the backwards-compatibility hack would need
> to turn on a level of unsafety that extension scripts
On Thu, Jun 20, 2019 at 5:00 PM David Fetter wrote:
> Is there perhaps a way to make raising max_connections not require a
> restart? There are plenty of situations out there where restarts
> aren't something that can be done on a whim.
Sure, if you want to make this take about 100x more work.
On Mon, 24 Jun 2019 at 00:42, Tomas Vondra wrote:
>
> On Sun, Jun 23, 2019 at 10:23:19PM +0200, Tomas Vondra wrote:
> >On Sun, Jun 23, 2019 at 08:48:26PM +0100, Dean Rasheed wrote:
> >>On Sat, 22 Jun 2019 at 15:10, Tomas Vondra
> >>wrote:
> >>>One annoying thing I noticed is that the
On Mon, Jun 24, 2019 at 01:44:14PM +0200, Dmitry Dolgov wrote:
On Sun, Jun 23, 2019 at 1:04 PM Floris Van Nee wrote:
However, _bt_readpage messes things up, because it only reads tuples that
match all the provided keys (so where b=2)
Right, the problem you've reported first had a similar
On Sat, Apr 7, 2018 at 4:56 PM, Alexander Korotkov <
a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> I agree with that. For bounded sort, attached patch now selects minimal
> group
> size as Min(DEFAULT_MIN_GROUP_SIZE, bound). That should improve
> "LIMIT small_number" case.
As I was working on
On 6/23/19 10:27 PM, Michael Paquier wrote:
> On Sun, Jun 23, 2019 at 06:15:06PM -0400, Andrew Dunstan wrote:
>> Alvaro pointed out to me recently that the buildfarm client doesn't have
>> any provision for running module tests like commit_ts and
>> snapshot_too_old that use NO_INSTALLCHECK. On
>From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
>Sent: Friday, April 26, 2019 11:50 PM
>To: 'Kyotaro HORIGUCHI' ;
>thomas.mu...@enterprisedb.com; robertmh...@gmail.com
>Cc: pgsql-hack...@postgresql.org
>Subject: RE: Copy data to DSA area
>
>Hi, I've updated Thomas's quick PoC.
Hi.
On 2019-Jun-24, Michael Paquier wrote:
> On Fri, Jun 14, 2019 at 06:31:52PM -0400, Alvaro Herrera wrote:
> > BTW I tested this manually and it seemed to work as intended, ie., if I
> > change /etc/hosts for the hostname I am using between one connection and
> > the next, we do keep the hostaddr
> On Sun, Jun 23, 2019 at 1:04 PM Floris Van Nee
> wrote:
>
> However, _bt_readpage messes things up, because it only reads tuples that
> match all the provided keys (so where b=2)
Right, the problem you've reported first had a similar origins. I'm starting to
think that probably using
Hi!
> 24 июня 2019 г., в 15:08, Darafei Komяpa Praliaskouski
> написал(а):
>
> I'm looking at PostGIS geometry GiST index build times and try to optimize
> withing the current GiST framework. The function that shows a lot on my flame
> graphs is penalty.
>
> I spent weekend rewriting
On Mon, 24 Jun 2019 at 22:16, Michael Paquier wrote:
>
> On Sat, Jun 15, 2019 at 12:25:12PM +1200, David Rowley wrote:
> > With the attached version I'm just calling table_finish_bulk_insert()
> > once per partition at the end of CopyFrom(). We've got an array with
> > all the ResultRelInfos we
On Sat, Jun 15, 2019 at 12:25:12PM +1200, David Rowley wrote:
> With the attached version I'm just calling table_finish_bulk_insert()
> once per partition at the end of CopyFrom(). We've got an array with
> all the ResultRelInfos we touched in the proute, so it's mostly a
> matter of looping over
Hi,
I'm looking at PostGIS geometry GiST index build times and try to optimize
withing the current GiST framework. The function that shows a lot on my
flame graphs is penalty.
I spent weekend rewriting PostGIS penalty to be as fast as possible.
(FYI
Michael Paquier writes:
> On Sun, Jun 23, 2019 at 09:56:40PM +0200, Peter Eisentraut wrote:
>> On 2019-06-21 15:45, Dagfinn Ilmari Mannsåker wrote:
>>> Also, on Linux it requires libbsd: https://libbsd.freedesktop.org/
>>
>> No, it's in glibc.
>
> From man:
> explicit_bzero() first appeared in
Thank you, Tom.
(And sorry for the delay following up.)
I’ve marked myself down for review for this patch in the next CF.
I’ll see if I can get the patch applied and feed back on how much it move
towards making my use case a viable proposition.
d.
> On 9 Jun 2019, at 17:21, Tom Lane
I wrote:
> I'll look for other rules that could be more
> easily optimized, but I'm not terribly optimistic.
I found a possible other way to bring the size of the transition table
under 32k entries while keeping the existing no-backup rules in place:
Replace the "quotecontinue" rule with a new
> 18 мая 2019 г., в 11:44, Andrey Borodin написал(а):
>
Hi!
Here's rebased version of patches.
Best regards, Andrey Borodin.
0001-Use-memcpy-in-pglz-decompression-for-long-matches.patch
Description: Binary data
0001-Use-memcpy-in-pglz-decompression.patch
Description: Binary data
On Fri, Jun 14, 2019 at 06:31:52PM -0400, Alvaro Herrera wrote:
> BTW I tested this manually and it seemed to work as intended, ie., if I
> change /etc/hosts for the hostname I am using between one connection and
> the next, we do keep the hostaddr if it was specified, or we resolve the
> name
Hi,
patch no longer applies (as of 12beta2).
postgres@ubuntudev:~/pg_testing/source/postgresql-12beta2$ patch -p1 <
drop-database-force-20190310_01.patch
patching file doc/src/sgml/ref/drop_database.sgml
patching file doc/src/sgml/ref/dropdb.sgml
patching file src/backend/commands/dbcommands.c
Heikki,
On Thu, Apr 04, 2019 at 06:15:21PM +0300, Heikki Linnakangas wrote:
> I think we should fix this in a similar manner in B-tree, too, but that can
> be done separately. For B-tree, we need to worry about
> backwards-compatibility, but that seems simple enough; we just need to
> continue to
Hi,
In commit a76200de we added a line to unset MAKELEVEL to fix a problem
with our temp-install logic. I don't think it was a great idea to
clear MAKEFLAGS at the same time, because now when you type "make -s
-j8" on a non-GNU system it ignores you and is loud and slow.
Admittedly there is
75 matches
Mail list logo
