Hi all,
I just bumped into the following typo that has been introduced by e50cda7:
--- a/doc/src/sgml/ref/pg_rewind.sgml
+++ b/doc/src/sgml/ref/pg_rewind.sgml
@@ -71,7 +71,7 @@ PostgreSQL documentation
missing files from a WAL archive automatically is currently not supported.
Besides, pg_r
On Thu, Dec 24, 2015 at 1:57 PM, Pavel Stehule wrote:
>
>
> 2015-12-24 3:23 GMT+01:00 Michael Paquier :
>>
>> On Thu, Dec 17, 2015 at 6:45 PM, Shulgin, Oleksandr
>> wrote:
>> > On Wed, Dec 16, 2015 at 8:39 PM, Tomas Vondra
>> >
>> > wrote:
>> >> On 12/01/2015 10:34 AM, Shulgin, Oleksandr wrote:
Hi,
On 2015/12/23 7:23, Stephen Frost wrote:
> Updated patch attached. I'll give it another good look and then commit
> it, barring objections.
Just a minor nitpick about a code comment -
/*
+ * Check that the user is not trying to create a role in the reserved
+ * "pg_" namespace
Hello Michaël,
If I read you correctly, I should cut it out into a new file and
include it. Is it correct?
Not really, I meant to see if it would be possible to include this set
of routines directly in libpqcommon (as part of OBJS_FRONTEND). This
way any client applications could easily reuse
AFAICR with xlog-triggered checkpoints, the checkpointer progress is
measured with respect to the size of the WAL file, which does not grow
linearly in time for the reason you pointed above (a lot of FPW at the
beginning, less in the end). As the WAL file is growing quickly, the
checkpointer thi
On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes wrote:
>
> On further thought, neither do I. The attached patch inverts
> ResolveRecoveryConflictWithLock to be called back from the lmgr code so that
> is it like ResolveRecoveryConflictWithBufferPin code. It does not try to
> cancel the conflicting
On Wed, Dec 23, 2015 at 7:48 PM, Peter Geoghegan wrote:
> I wonder, what's the situation here like with the attached patch
> applied on top of what you were testing? I think that we might be
> better off with more merge steps when under enormous memory pressure
> at the low end, in order to be abl
2015-12-24 3:23 GMT+01:00 Michael Paquier :
> On Thu, Dec 17, 2015 at 6:45 PM, Shulgin, Oleksandr
> wrote:
> > On Wed, Dec 16, 2015 at 8:39 PM, Tomas Vondra <
> tomas.von...@2ndquadrant.com>
> > wrote:
> >> On 12/01/2015 10:34 AM, Shulgin, Oleksandr wrote:
> >>>
> >>>
> >>> I have the plans to ma
On 24 December 2015 at 16:32, Tomas Vondra
wrote:
>
>
> On 12/24/2015 03:45 AM, Michael Paquier wrote:
>
>> On Wed, Sep 30, 2015 at 10:12 AM, David Rowley
>>
> ...
>
>> In the attached I've coded it to take the Min() selectivity for when the
>>> same quals are matched more than once. I know this
On Thu, Dec 24, 2015 at 2:37 AM, Tom Lane wrote:
> "Shulgin, Oleksandr" writes:
>> 1. Have you considered re-loading the HBA file upon call to this function
>> in a local context instead of keeping it in the backends memory?
>
> Aside from the security questions, please consider that this feature
On Tue, Dec 22, 2015 at 05:23:47PM -0500, Stephen Frost wrote:
> > >> On Tue, Dec 22, 2015 at 1:41 AM, Stephen Frost
> > >> wrote:
> > >>> Updated and rebased patch attached which takes the 'pg_switch_xlog'
> > >>> default role back out, leaving us with:
> > >>>
> > >>> pg_monitor - View privileg
On Wed, Dec 23, 2015 at 1:03 PM, Jeff Janes wrote:
> The regression I found when building an index on a column of
> 400,000,000 md5(random()::text) with 64MB maintenance_work_mem was not
> hard to find at all. I still don't understand what is going on with
> it, but it is reproducible. Perhaps i
On 12/24/2015 03:45 AM, Michael Paquier wrote:
On Wed, Sep 30, 2015 at 10:12 AM, David Rowley
...
In the attached I've coded it to take the Min() selectivity for when the
same quals are matched more than once. I know this is not correct, but since
it seems impossible to obtain an exact estima
Hi,
On 12/24/2015 04:05 AM, Michael Paquier wrote:
On Mon, Dec 7, 2015 at 7:48 AM, Tomas Vondra
wrote:
...
Otherwise the reworked patch seems fine to me, but I'll give it a bit more
testing over the next few days.
Thanks for the help so far!
Tomas, are you still working on that? This th
On Wed, Dec 23, 2015 at 6:14 PM, Michael Paquier
wrote:
> On Wed, Nov 4, 2015 at 12:08 PM, Amit Kapila wrote:
>> On Tue, Nov 3, 2015 at 8:07 PM, Simon Riggs wrote:
>>>
>>> On 3 November 2015 at 15:23, Amit Kapila wrote:
On Fri, Oct 23, 2015 at 6:29 AM, Simon Riggs
wrote:
>
>
On Tue, Dec 22, 2015 at 10:45 PM, Michael Paquier
wrote:
> On Tue, Dec 22, 2015 at 4:04 PM, Michael Paquier
> wrote:
>> OK, if those don't get addressed soon, they will be moved to the next
>> CF with the same status.
>
> After a first pass, Numbers are getting down, I am just too tired to
> co
On Mon, Dec 7, 2015 at 7:48 AM, Tomas Vondra
wrote:
> Hello Kyotaro-san,
>
> Sorry for the long delay since your response in this thread :-(
>
> On 10/14/2015 08:06 AM, Kyotaro HORIGUCHI wrote:
>>
>>
>> The table t is referred to twice by different (alias) names (though
>> the diferrence is made b
On Tue, Dec 22, 2015 at 5:59 PM, Pavel Stehule wrote:
> Hi
>
> 2015-12-21 16:21 GMT+01:00 Artur Zakirov :
>>
>> Hi.
>> I have tried to do some review of this patch. Below are my comments.
>>
>> Introduction:
>>
>> This patch fixes and adds the following functionality:
>> - %TYPE - now can be used
On Mon, Nov 9, 2015 at 8:55 PM, Ashutosh Bapat
wrote:
>
>
> On Sat, Nov 7, 2015 at 12:07 AM, Robert Haas wrote:
>>
>> On Wed, Aug 12, 2015 at 6:25 AM, Ashutosh Bapat
>> wrote:
>> > The previous patch would not compile on the latest HEAD. Here's updated
>> > patch.
>>
>> Perhaps unsurprisingly, t
On Wed, Dec 23, 2015 at 12:15 PM, Thomas Munro
wrote:
> Review stuff
I have moved this entry to next CF as review is quite recent.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
On Thu, Sep 24, 2015 at 3:33 PM, Jeff Janes wrote:
> On Wed, Sep 16, 2015 at 2:44 PM, Simon Riggs wrote:
>>
>> On 14 September 2015 at 12:00, Jeff Janes wrote:
>>
It's now possible to fix this by putting a lock wait on the actual lock
request, which wasn't available when I first w
On Sun, Dec 13, 2015 at 11:05 PM, Amit Kapila wrote:
> On Fri, Dec 11, 2015 at 6:34 PM, Andres Freund wrote:
>>
>> On 2015-12-11 15:56:46 +0300, Alexander Korotkov wrote:
>> >
>> > Yes, there is a cycle with retries in LWLockAcquire function. The case
>> > of
>> > retry is when waiter is waked up
On Tue, Dec 15, 2015 at 12:07 PM, Tomas Vondra
wrote:
> Hi,
>
> On 12/07/2015 03:05 PM, Stas Kelvich wrote:
>>
>> Hello.
>>
>> Done with the list of suggestions. Also heavily edit delete function.
>>
>
> I did a quick review of the updated patch. I'm not a tsvector-expert so
> hopefully my comment
On Wed, Dec 23, 2015 at 6:16 PM, Amit Kapila wrote:
> blah.
autovacuum log: Moved to next CF as thread is really active.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Nov 23, 2015 at 6:29 PM, Dean Rasheed wrote:
> On 21 November 2015 at 03:54, Marko Tiikkaja wrote:
>> Here's v2 of the patch. How's this look?
>>
>
> Here are some initial review comments:
>
> * My first thought on reading this patch is that it is somewhat
> under-commented. For example,
On 2015/12/23 8:45, Peter Geoghegan wrote:
> On Tue, Dec 22, 2015 at 3:38 PM, Robert Haas wrote:
>> In my opinion a term more closely coupled to the concrete syntax would
>> be easier to understand. I have no objection to referring to the
>> *process* of trying to deduce a suitable index from the
On Wed, Sep 30, 2015 at 10:12 AM, David Rowley
wrote:
> On 29 September 2015 at 01:59, Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> On 09/27/2015 02:00 PM, David Rowley wrote:
>>>
>>> I've been working on this again. I've put back the code that you wrote
>>> for the looping over each combination of rela
On Thu, Dec 17, 2015 at 10:17 PM, David Rowley
wrote:
> On 17 December 2015 at 19:11, Simon Riggs wrote:
>>
>> On 17 December 2015 at 00:17, Tomas Vondra
>> wrote:
>>>
>>> I'd go with match_first_tuple_only.
>>
>>
>> +1
>>
>> unique_inner is a state that has been detected, match_first_tuple_only
On Thu, Dec 24, 2015 at 8:44 AM, Peter Geoghegan wrote:
> [long blahblah]
(Patch moved to next CF, work is going on. Thanks to people here to be active)
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
On Wed, Dec 16, 2015 at 2:53 AM, Tomas Vondra
wrote:
> Actually, one more thing - the patch should probably update the docs too,
> because client-auth.sgml currently says this in the "auth-pam" section:
>
>
> ...
> PAM is used only to validate user name/password pairs.
> ...
>
On Tue, Nov 17, 2015 at 8:36 PM, Vladimir Borodin wrote:
>
> 14 нояб. 2015 г., в 10:50, Amit Kapila написал(а):
>
> On Wed, Sep 16, 2015 at 11:22 PM, Robert Haas wrote:
>> On Wed, Sep 16, 2015 at 12:29 PM, Alexander Korotkov
>> wrote:
>>
>> >> I think it's reasonable to consider reporting this
On Thu, Dec 24, 2015 at 1:12 PM, David Rowley
wrote:
> On 24 December 2015 at 13:55, Haribabu Kommi
> wrote:
>>
>> On Wed, Dec 23, 2015 at 7:50 PM, David Rowley
>> wrote:
>> > One other part that I'm not too sure on how to deal with is how to set
>> > the
>> > data type for the Aggrefs when we'r
On Thu, Dec 3, 2015 at 5:31 AM, Pavel Stehule wrote:
> There is: SplitIdentifierString or textToQualifiedNameList in varlena.c. My
> first patch was based on these functions. But I cannot to use it.
>
> 1. major reason: The buildin parser is based on searching the dot "." and
> doesn't search any
On Thu, Dec 17, 2015 at 6:45 PM, Shulgin, Oleksandr
wrote:
> On Wed, Dec 16, 2015 at 8:39 PM, Tomas Vondra
> wrote:
>> On 12/01/2015 10:34 AM, Shulgin, Oleksandr wrote:
>>>
>>>
>>> I have the plans to make something from this on top of
>>> pg_stat_statements and auto_explain, as I've mentioned la
On 24 December 2015 at 03:43, Jim Nasby wrote:
> On 12/21/15 7:49 PM, Craig Ringer wrote:
>
>> CREATE JOIN STATISTICS ON t1 JOIN t2 USING (somecol);
>>
>>
>> That way we let an admin who's tuning queries direct effort at problem
>> areas. It's not automagical, but it's an area where tools could a
On Thu, Dec 24, 2015 at 4:36 AM, Tom Lane wrote:
> As written, this would leak password strings, and it even seems possible
> that it would leave savedPassword pointing at dangling memory, since the
> free(password) inside the loop might free what savedPassword is pointing
> at, and then in princi
On 22 December 2015 at 23:46, Tom Lane wrote:
> > In which version(s) of Windows was this improvement added?
Vista and Server 2008 (original, not R2).
https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx
Win7 and Server 2003 are already irrelevant now, and will be a
On 12/23/2015 06:14 PM, Craig Ringer wrote:
On 22 December 2015 at 23:48, Alex Ignatov mailto:a.igna...@postgrespro.ru>> wrote:
I think that you can debug crash dump since windbg exists.
Nobody in their right mind uses windbg though. Visual Studio is really
where it's at and the Express ve
On Mon, Dec 7, 2015 at 9:14 PM, Michael Paquier
wrote:
>
>
> On Wed, Sep 2, 2015 at 6:19 AM, Marko Tiikkaja wrote:
>>
>> Hopefully nobody minds if I slip this to the commit fest that started
>> today? The attached patch should address all the comments from the 9.5
>> cycle.
>
>
> All the previou
On Wed, Nov 4, 2015 at 12:08 PM, Amit Kapila wrote:
> On Tue, Nov 3, 2015 at 8:07 PM, Simon Riggs wrote:
>>
>> On 3 November 2015 at 15:23, Amit Kapila wrote:
>>>
>>> On Fri, Oct 23, 2015 at 6:29 AM, Simon Riggs
>>> wrote:
Easy enough to do it at the end of the COPY FREEZE in one step
On 22 December 2015 at 23:48, Alex Ignatov wrote:
> I think that you can debug crash dump since windbg exists.
>
Nobody in their right mind uses windbg though. Visual Studio is really
where it's at and the Express versions make it much more practical.
You can't even install Debugging Tools for
On 24 December 2015 at 13:55, Haribabu Kommi
wrote:
> On Wed, Dec 23, 2015 at 7:50 PM, David Rowley
> wrote:
> > One other part that I'm not too sure on how to deal with is how to set
> the
> > data type for the Aggrefs when we're not performing finalization on the
> > aggregate node. The return
On 24 December 2015 at 14:07, Haribabu Kommi
wrote:
> On Wed, Dec 23, 2015 at 7:50 PM, David Rowley
> wrote:
> > This is just my serial format that I've come up with for NumericAggState,
> > which is basically: "N sumX maxScale maxScaleCount NaNcount". Perhaps we
> can
> > come up with something
On 23 December 2015 at 21:50, David Rowley
wrote:
> Apart from the problems I listed above, I'm reasonably happy with the
> patch now, and I'm ready for someone else to take a serious look at it.
>
I forgot to mention another situation where this patch might need a bit
more thought. This does n
On Tue, Dec 22, 2015 at 10:49 AM, Peter Geoghegan wrote:
> On Tue, Dec 22, 2015 at 9:31 AM, Robert Haas wrote:
>>> It has some nice properties, because unsigned integers are so simple
>>> and flexible. For example, we can do it with int4 sometimes, and then
>>> compare two attributes at once on 6
Hi,
On 12/23/2015 08:22 PM, Robert Haas wrote:
On Wed, Dec 23, 2015 at 2:16 PM, Tomas Vondra
wrote:
Another point (which Jan Wieck made me think of) is that the optimal
behavior here likely depends on whether xlog and data are on the same
disk controller. If they aren't, the FPW spike and back
On Wed, Dec 23, 2015 at 7:50 PM, David Rowley
wrote:
> This is just my serial format that I've come up with for NumericAggState,
> which is basically: "N sumX maxScale maxScaleCount NaNcount". Perhaps we can
> come up with something better, maybe just packing the ints and int64s into a
> bytea typ
On Wed, Dec 23, 2015 at 7:50 PM, David Rowley
wrote:
> One other part that I'm not too sure on how to deal with is how to set the
> data type for the Aggrefs when we're not performing finalization on the
> aggregate node. The return type for the Aggref in this case will be either
> the transtype,
On Thu, Dec 24, 2015 at 2:08 AM, Joe Conway wrote:
> On 12/23/2015 05:45 AM, Michael Paquier wrote:
>>> Yeah, the last version of the patch dates of August, and there is
>>> visibly agreement that the information of pg_controldata provided at
>>> SQL level is useful while the data of pg_config is
On 12/23/2015 08:10 AM, Ildus Kurbangaliev wrote:
There is a more improved version of the patch. Main idea is to present
uuid as two uint64 values, and make comparisons and penalty calculation
based on these values. This approach is much faster than using memcmp
for uuid comparisons.
Thank you
On Tue, Dec 22, 2015 at 5:34 PM, Kyotaro HORIGUCHI
wrote:
> I wrote:
>> Wouldn't it be better with something say in src/common
>> which is frontend-only? We could start with a set of routines allowing
>> commands to be parsed. That gives us more room for future improvement.
>
> If I read you corre
On Thu, Dec 24, 2015 at 1:55 AM, Alvaro Herrera
wrote:
> Tom Lane wrote:
>
>> Sorry for having lost track of this. I think if we're going to do this,
>> we should do it now not later, because it essentially reverts the
>> connectDatabase() API change made in 83dec5a71 in favor of a different API
On Wed, Dec 23, 2015 at 1:16 PM, Robert Haas wrote:
> On Wed, Dec 23, 2015 at 3:31 PM, Peter Geoghegan wrote:
>> On Wed, Dec 23, 2015 at 9:37 AM, Robert Haas wrote:
>>> The point is, nobody can tell WHAT effects this is modeling.
>>> Increasing the tuple size makes the crossover go up. Or down.
On Wed, Dec 23, 2015 at 2:34 AM, Dilip Kumar wrote:
> Yeah right, After applying all three patches this problem is fixed, now
> parallel hash join is faster than normal hash join.
>
> I have tested one more case which Amit mentioned, I can see in that case
> parallel plan (parallel degree>= 3) is
On Wed, Dec 23, 2015 at 3:31 PM, Peter Geoghegan wrote:
> On Wed, Dec 23, 2015 at 9:37 AM, Robert Haas wrote:
>> The point is, nobody can tell WHAT effects this is modeling.
>> Increasing the tuple size makes the crossover go up. Or down.
>
> There are multiple, competing considerations.
Please
On Wed, Dec 23, 2015 at 1:03 PM, Jeff Janes wrote:
> If we do think it is important to almost never cause regressions at
> the default maintenance_work_mem (I am agnostic on the importance of
> that), then I think we have more work to do here. I just don't know
> what that work is.
My next revis
On Mon, Dec 14, 2015 at 7:22 PM, Peter Geoghegan wrote:
> On Mon, Dec 14, 2015 at 6:58 PM, Greg Stark wrote:
>> I ran sorts with various parameters on my small NAS server.
>
> ...
>
>> without the extra memory optimizations.
>
> Thanks for taking the time to benchmark the patch!
>
> While I think
Hi,
Here's an updated patch that replaces sorted arrays by AVL binary trees
when gathering distinct values for the columns involved in the pivot.
The change is essential for large resultsets. For instance,
it allows to process a query like this (10 million rows x 10 columns):
select x,(random(
On Mon, Dec 21, 2015 at 11:51 AM, Tomas Vondra
wrote:
>
>
> On 12/21/2015 07:41 PM, Jeff Janes wrote:
>>
>> On Sat, Dec 19, 2015 at 3:19 PM, Tomas Vondra
>> wrote:
>
>
> ...
>
>>> So both patches seem to do the trick, but (2) is faster. Not sure
>>> if this is expected. (BTW all the results are w
On Wed, Dec 23, 2015 at 9:37 AM, Robert Haas wrote:
> The point is, nobody can tell WHAT effects this is modeling.
> Increasing the tuple size makes the crossover go up. Or down.
There are multiple, competing considerations.
> This analogy is faulty. It's true that when we run across a qual
>
On 12/23/15 12:15 PM, Corey Huinker wrote:
That's fair. I'm still at a loss for how to show that the fetch size was
respected by the remote server, suggestions welcome!
A combination of repeat() and generate_series()?
I'm guessing it's not that obvious and that I'm missing something; can
you
On 12/23/15 12:26 PM, Robert Haas wrote:
What's the lightest-weight object I can create that has an owner,
>and whose disappearance I can be notified of?
Schema?
I was thinking view or function, since then you can hide all of them in
an internal-only schema.
BTW, I've been pondering a very
On 12/21/15 8:36 AM, Tom Lane wrote:
but it might be nice to have some number as to how
> reliable a certain estimate is, which is high if the estimate is, say,
> derived from a single filter on a base table and sinks as more conditions
> are involved or numbers pulled out of thin air.
On 12/21/15 7:49 PM, Craig Ringer wrote:
CREATE JOIN STATISTICS ON t1 JOIN t2 USING (somecol);
That way we let an admin who's tuning queries direct effort at problem
areas. It's not automagical, but it's an area where tools could analyze
pg_stat_statements to direct effort, much like is current
Michael Paquier writes:
> OK, I think that we had better address this bug for this CF. I am
> attaching an updated patch following Marko's suggestion, and marking
> this patch as ready for committer. I have noticed that the fix was
> actually not complete: ConnectDatabase needs a similar fix, this
On Wed, Dec 23, 2015 at 5:50 AM, Rushabh Lathia
wrote:
> +1.
>
> I like idea of separate FDW API for the DML Pushdown. Was thinking can't we
> can re-use the IterateForeignScan(ForeignScanState *node) rather then
> introducing IterateDMLPushdown(ForeignScanState *node) new API ?
Yeah, I think we
On 12/21/2015 01:11 PM, Heikki Linnakangas wrote:
On 21/12/15 13:53, Tomas Vondra wrote:
On 12/21/2015 12:03 PM, Heikki Linnakangas wrote:
On 17/12/15 19:07, Robert Haas wrote:
If it works well empirically, does it really matter that it's
arbitrary? I mean, the entire planner is full of fair
On Wed, Dec 23, 2015 at 2:16 PM, Tomas Vondra
wrote:
>> Another point (which Jan Wieck made me think of) is that the optimal
>> behavior here likely depends on whether xlog and data are on the same
>> disk controller. If they aren't, the FPW spike and background writes
>> may not interact as much.
On Wed, Dec 23, 2015 at 10:37 AM, Fabien COELHO wrote:
> Hmmm. Let us try with both hands:
>
> AFAICR with xlog-triggered checkpoints, the checkpointer progress is
> measured with respect to the size of the WAL file, which does not grow
> linearly in time for the reason you pointed above (a lot of
Hi,
On 12/23/2015 03:38 PM, Robert Haas wrote:
I think one thing that this conversation exposes is that the size of
the working set matters a lot. For example, if the workload is
pgbench, you're going to see a relatively short FPW-related spike at
scale factor 100, but at scale factor 3000 it's
On Wed, Dec 23, 2015 at 2:34 AM, Dilip Kumar wrote:
>> I think the gather-reader-order patch will fix this. Here's a test
>> with all three patches.
>
> Yeah right, After applying all three patches this problem is fixed, now
> parallel hash join is faster than normal hash join.
Thanks. I've com
On 12/23/2015 10:16 AM, Tom Lane wrote:
Depending on timing, this scheme might accidentally fail to fail, but it
seems fragile as can be. I would bet that it's prone to deadlocks, quite
aside from the SIGPIPE problem. Considering how amazingly ugly the
underlying code is (exit_horribly is in p
On Mon, Dec 21, 2015 at 3:09 PM, Chapman Flack wrote:
> On 12/21/2015 02:30 PM, Chapman Flack wrote:
>> On 12/21/2015 12:46 PM, Tom Lane wrote:
>
>>> all, since we don't provide a way for extensions to hook into the DROP
>>> mechanisms. Perhaps that should be fixed.)
>>
>> That is literally *the
On Mon, Dec 21, 2015 at 9:27 PM, Craig Ringer wrote:
> Right now the logs just have to be treated as security critical. Which
> sucks, but is not easily solved.
>
> Nothing is going to stop:
>
> ALTER USER fred PAWORD 'sekrit';
>
> from logging the password in a syntax error. But it'd be n
I was in process of testing the proposed patch for bug #13727,
and I found that at least on my Linux box, this is the behavior
in the failure case without the patch:
$ pg_dump "postgres://postgres:phonypassword@localhost/regression" --jobs=9 -Fd
-f testdump
$ echo $?
141
$ ls testdump
toc.dat
Th
On Wed, Dec 23, 2015 at 8:43 AM, Michael Paquier
wrote:
> On Mon, Sep 21, 2015 at 1:52 PM, Corey Huinker
> wrote:
> > Attached is the patch / diff against current master.
>
> I have moved this patch to next CF, there is a new patch, but no reviews.
> --
> Michael
>
That's fair. I'm still at a
On Mon, Dec 21, 2015 at 6:38 PM, David Rowley
wrote:
> On 22 December 2015 at 04:16, Paul Ramsey wrote:
>>
>> Shouldn’t parallel aggregate come into play regardless of scan
>> selectivity?
>
> I'd say that the costing should take into account the estimated number of
> groups.
>
> The more tuples
[...]
Because the schedule is based on a stochastic process, transactions are not
set regularly (that would induce patterns and is not representative of
real-life load) but randomly.
The long term average is expected to converge to 2 tps, but on a short run
it may differ significantly.
Hmm.
On Tue, Dec 22, 2015 at 8:10 PM, Peter Geoghegan wrote:
>> Sure, there are arbitrary numbers all over the code, driven by
>> empirical observations about what factors are important to model. But
>> this is not that. You don't have a thing called seq_page_cost and a
>> thing called cpu_tuple_cost
On 12/23/2015 05:45 AM, Michael Paquier wrote:
>> Yeah, the last version of the patch dates of August, and there is
>> visibly agreement that the information of pg_controldata provided at
>> SQL level is useful while the data of pg_config is proving to be less
>> interesting for remote users. Could
Tom Lane wrote:
> Sorry for having lost track of this. I think if we're going to do this,
> we should do it now not later, because it essentially reverts the
> connectDatabase() API change made in 83dec5a71 in favor of a different API
> change with the same purpose. Now, that doesn't matter if n
Michael Paquier writes:
> On Mon, Nov 16, 2015 at 11:41 AM, Haribabu Kommi
> wrote:
>> On Sun, Nov 15, 2015 at 12:39 AM, Michael Paquier
>> wrote:
>>> That's neater. See for example the attached.
>> Yes, it is much cleaner than the previous version.
>> I reviewed and tested the same. It is work
On Wed, Dec 23, 2015 at 11:23 AM, Fabien COELHO wrote:
>>> Probably no skips though, because the response time needed is below 5
>>> *seconds*, not ms : 2 tps on 10 connections, 1 transaction every 5
>>> seconds
>>> for each connection.
>>
>> Oops. Right. But why did this test only run 16 transa
Probably no skips though, because the response time needed is below 5
*seconds*, not ms : 2 tps on 10 connections, 1 transaction every 5 seconds
for each connection.
Oops. Right. But why did this test only run 16 transactions in total
instead of 20?
Because the schedule is based on a stoch
On Tue, 15 Sep 2015 09:03:00 +0300
Teodor Sigaev wrote:
> Paul Jungwirth wrote:
> >> Or something like this in pseudocode:
> >>
> >> numeric = int8_numeric(*(uint64 *)(&i->data[0])) *
> >> int8_numeric(MAX_INT64) + int8_numeric(*(uint64 *)(&i->data[8]))
> >
> > This is more like what I was hopi
Dmitry Ivanov writes:
>> That concern is exactly the reason why we never did this originally.
>> In particular, emitting raw INSERTs into pg_statistic is just plain
>> foolish; we have changed the rowtype of pg_statistic in the past and
>> are likely to do so again. At a minimum we would need suc
On Wed, Dec 23, 2015 at 9:52 AM, Fabien COELHO wrote:
>> In your example, you've got 10 connections and are trying to run at 2
>> tps, so to avoid having to start skipping things you need transaction
>> response times to be <~ 5 ms. The actual response time is ~5.5ms, so
>> if you ran the test fo
Hello Robert,
On a pgbench test, and probably many other workloads, the impact of
FPWs declines exponentially (or maybe geometrically, but I think
exponentially) as we get further into the checkpoint.
Indeed. If the probability of hitting a page is uniform, I think that the
FPW probability i
"Shulgin, Oleksandr" writes:
> 1. Have you considered re-loading the HBA file upon call to this function
> in a local context instead of keeping it in the backends memory?
Aside from the security questions, please consider that this feature should
work similarly to the current implementation of t
> That concern is exactly the reason why we never did this originally.
> In particular, emitting raw INSERTs into pg_statistic is just plain
> foolish; we have changed the rowtype of pg_statistic in the past and
> are likely to do so again. At a minimum we would need such a facility
> to be proof
Hello Robert & Tatsuo,
Some paraphrasing and additional comments.
$ pgbench -p 11002 --rate 2 --latency-limit 1 -c 10 -T 10 test
You are targetting 2 tps over 10 connections, so that is about one
transaction every 5 seconds for each connection, the target is about 20
transactions in 10 sec
On Wed, Dec 23, 2015 at 9:22 AM, Fabien COELHO wrote:
>> Wait, what? On what workload does the FPW spike last only a few
>> seconds? [...]
>
> Ok. AFAICR, a relatively small part at the beginning of the checkpoint, but
> possibly more that a few seconds.
On a pgbench test, and probably many othe
On Tue, Dec 22, 2015 at 9:28 PM, Tatsuo Ishii wrote:
> While playing with 9.5's pgbench, I faced with a strange behavior.
>
> $ pgbench -p 11002 --rate 2 --latency-limit 1 -c 10 -T 10 test
> starting vacuum...end.
> transaction type: TPC-B (sort of)
> scaling factor: 1
> query mode: simple
> numbe
Hello Robert,
I think that the 1.5 value somewhere in the patch is much too high for the
purpose because it shifts the checkpoint load quite a lot (50% more load at
the end of the checkpoint) just for the purpose of avoiding a spike which
lasts a few seconds (I think) at the beginning. A much s
On Wed, Dec 23, 2015 at 12:56 PM, Haribabu Kommi
wrote:
> On Wed, Dec 23, 2015 at 8:54 PM, Shulgin, Oleksandr
> wrote:
> >
> > 1. Have you considered re-loading the HBA file upon call to this
> function in
> > a local context instead of keeping it in the backends memory? I do not
> > expect tha
On Wed, Dec 23, 2015 at 8:56 PM, Haribabu Kommi
wrote:
> On Wed, Dec 23, 2015 at 8:54 PM, Shulgin, Oleksandr
> wrote:
>> 5. Some tests demonstrating possible output would be really nice to have.
>
> Do you mean regression tests? In case of install check case, the results are
> based on the serve
Hi Alvaro,
May be you know, that I have implemented IMCS (in-memory-columnar-store)
as PostgreSQL extension.
It was not so successful, mostly because people prefer to use standard
SQL rather than using some special functions for accessing columnar
storage (CS). Now I am thinking about second r
On Tue, Dec 15, 2015 at 10:41 AM, Tomas Vondra
wrote:
> On 10/16/2015 08:00 PM, Jinyu Zhang wrote:
>> Update the patch_brin_optimze_mem according to your comment.
>
> I've reviewed the last version of the patch, and I do have a few comments. I
> haven't done any performance testing at this point,
On Wed, Dec 9, 2015 at 9:18 PM, Michael Paquier
wrote:
> On Thu, Sep 17, 2015 at 7:12 AM, Andres Freund wrote:
>> On 2015-08-20 09:59:25 -0400, Andrew Dunstan wrote:
>>> Is there any significant interest in either of these?
>>>
>>> Josh Berkus tells me that he would like pg_controldata informatio
On Mon, Sep 21, 2015 at 1:52 PM, Corey Huinker wrote:
> Attached is the patch / diff against current master.
I have moved this patch to next CF, there is a new patch, but no reviews.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
1 - 100 of 106 matches
Mail list logo
