On 2015/09/09 3:53, Robert Haas wrote:
On Tue, Sep 8, 2015 at 5:35 AM, Etsuro Fujita
wrote:
On 2015/09/04 0:33, Robert Haas wrote:
I'm worried that trawling through that
SpecialJoinInfo data will end up needing to duplicate much of
make_join_rel and
On Wed, Sep 9, 2015 at 3:27 AM, Alexander Korotkov
wrote:
> On Tue, Sep 8, 2015 at 10:28 AM, Michael Paquier
> wrote:
>
>> I am planning to do as well a detailed code review rather soon.
>>
>
> Good, thanks.
>
When testing a bit more complex
next iteration - fixed bug in parsing UTF8 chars, enhanced error messages.
Regards
Pavel
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index b3b78d2..75ea33a
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
***
*** 1707,1712
---
In the sgml, second should be plural in 'intead of the number of second
since the'. And 'intead' should be 'instead'.
Ok.
--progress-timestamp use a Unix-like epoch timestamp for progress
reporting
but that is getting pretty long.
Indeed. I've done:
--progress-timestamp use
2015-09-08 18:53 GMT+02:00 Shulgin, Oleksandr
:
> On Tue, Sep 8, 2015 at 11:49 AM, Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de> wrote:
>
>>
>> >> The real problem could be if the process that was signaled to connect
>> to the message queue never handles the
Hello Amit,
I think that we may conclude, on these run:
(1) sorting seems not to harm performance, and may help a lot.
I agree with first part, but about helping a lot, I am not sure
I'm focussing on the "sort" dimension alone, that is I'm comparing the
average tps performance with
>
> It is expected, and documented. (It's also different in 9.5, see
>
> http://git.postgresql.org/gitweb/?p=postgresql.git=commitdiff=c6b3c939b7e0f1d35f4ed4996e71420a993810d2
> )
>
Ah, thanks!
> > If nothing else, it seems that the concatenation operator should be
> listed
> > on the operator
On Thu, Sep 3, 2015 at 8:21 PM, Amit Kapila wrote:
> On Thu, Jul 23, 2015 at 7:43 PM, Kouhei Kaigai wrote:
>>
>> Hi Amit,
>>
>> The latest v16 patch cannot be applied to the latest
>> master as is.
>> 434873806a9b1c0edd53c2a9df7c93a8ba021147 changed
On Wed, Sep 9, 2015 at 4:12 AM, Robbie Harwood wrote:
> Michael Paquier writes:
> As promised, here's a V2 to address your issues with comments. I
> haven't heard back on the issues you found in testing, so no other
> changes are present.
Well, the issue is still here: login through gssapi fails
On Wed, Sep 9, 2015 at 8:36 AM, Pavel Stehule
wrote:
>
>> Please find attached v4.
>>
>
> It is better
>
One important thing to notice, and probably deserves a code comment, that
any modification of the slot fields done by the info sender backend must be
done before
Two notices:
>
> 1. The communication mechanism can be used more wide, than only for this
> purpose. We can introduce a SendInfoHook - and it can be used for any
> customer probes - memory, cpu, ...
>
Not sure if for CPU you can get any more insight than an external tool like
top(1) will provide.
On 2015/07/10 18:40, Etsuro Fujita wrote:
> To save cycles, I modified create_foreignscan_plan so that it detects
> whether any system columns are requested if scanning a base relation.
> Also, I revised other code there a little bit.
Attached is an updated version of the patch. The previous
On Tue, Sep 8, 2015 at 8:01 PM, Robert Haas wrote:
> On Mon, Sep 7, 2015 at 7:33 AM, Ildus Kurbangaliev
> wrote:
> >> > Ildus, could you please review Amit & Robert's patch?
> >> [1] -
> >>
>
On Wed, Sep 9, 2015 at 10:22 AM, Shulgin, Oleksandr <
oleksandr.shul...@zalando.de> wrote:
> On Wed, Sep 9, 2015 at 8:36 AM, Pavel Stehule
> wrote:
>
>>
>>> Please find attached v4.
>>>
>>
>> It is better
>>
>
> One important thing to notice, and probably deserves a code
В письме от 8 сентября 2015 11:53:24 Вы написали:
> On Sat, Sep 5, 2015 at 1:05 AM, Nikolay Shaplov wrote:
> > В письме от 4 сентября 2015 14:58:29 пользователь Michael Paquier написал:
> > > Documentation is missing, that would be good to have to understand what
> > > each function is intended to
On Wed, Sep 2, 2015 at 2:02 AM, Robert Haas wrote:
> On Mon, Aug 31, 2015 at 8:01 AM, Ashutosh Bapat
> wrote:
> >> Thanks. It needs testing though to see if it really works as
> >> intended. Can you look into that?
> >
> > PFA the patch
On Wed, Sep 9, 2015 at 9:01 AM, Michael Paquier
wrote:
>
>
> On Wed, Sep 9, 2015 at 3:27 AM, Alexander Korotkov
> wrote:
>
>> On Tue, Sep 8, 2015 at 10:28 AM, Michael Paquier
>> wrote:
>>
>>> I am planning to do as
On Sun, Sep 6, 2015 at 8:25 AM, Andres Freund wrote:
> On 2015-08-10 07:03:02 +0100, Simon Riggs wrote:
>> I was previously a proponent of (2) as a practical way forwards, but my
>> proposal here today is that we don't do anything further on 2) yet, and
>> seek to make
On Tue, Sep 8, 2015 at 5:02 PM, Tomas Vondra
wrote:
> Also, I'm not sure what other places do you have in mind (could you list
> some examples?) but I'd bet we limit the allocation to 1GB because of the
> palloc() limit and not because of fear of over-estimates.
I
On Wed, Sep 9, 2015 at 8:14 AM, Ashutosh Bapat
wrote:
> PFA patch with improved test module and fix for a bug.
>
> bgworker_sigusr1_handler() should set the latch when set_latch_on_sigusr1 is
> true, similar to procsignal_sigusr1_handler(). Without this fix, if a
On Tue, Sep 8, 2015 at 4:58 PM, Pavel Stehule wrote:
> 2015-09-08 22:55 GMT+02:00 Daniel Verite :
>>
>> Pavel Stehule wrote:
>>
>> > rotate ~ sounds like transpose matrix, what is not true in this case.
>
> for me the relation rotation is
>
>
> \x doesn't exactly rotate it either. \x puts the column headers down
> the side instead of across the top, but it doesn't put the rows across
> the top instead of down the side. Rather, each row is listed in a
> separate chunk.
true, it is rotation per one row. I was wrong.
> This
Andrew Dunstan writes:
> On 09/05/2015 12:55 PM, Tom Lane wrote:
>> Or we could just give up and replace the counts by INT_MAX, forcing use
>> of the pager unless you've turned it off. All of those outputs are long
>> enough now that it's hard to believe there are any common
Robert Haas writes:
> ... How often such a workload actually has to replace a *dirty* clog
> buffer obviously depends on how often you checkpoint, but if you're
> getting ~28k TPS you can completely fill 32 clog buffers (1 million
> transactions) in less than 40 seconds,
On Fri, Sep 4, 2015 at 4:48 PM, Amit Kapila wrote:
> On Thu, Sep 3, 2015 at 6:07 PM, Fujii Masao wrote:
>>
>> On Tue, Aug 4, 2015 at 12:15 PM, Amit Kapila
>> wrote:
>> > On Mon, Aug 3, 2015 at 7:44 PM, Fujii Masao
On Tue, Sep 8, 2015 at 2:28 PM, Andres Freund wrote:
> On 2015-09-08 15:58:26 +0800, 周正中(德歌) wrote:
>> postgres@digoal-> cat 7.sql
>> select txid_current();
>>
>> postgres@digoal-> pgbench -M prepared -n -r -P 1 -f ./7.sql -c 1 -j 1 -T
>> 10
>> About 32K tps.
>> progress:
Noah,
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Sep 08, 2015 at 02:58:36PM -0400, Stephen Frost wrote:
> > * Andrew Dunstan (and...@dunslane.net) wrote:
> > > Improve logging of TAP tests.
> >
> > [...]
> >
> > This broke 'make check' for REL9_4_STABLE with --enable-tap-tests
> >
On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund wrote:
> My vote is that we should try to get freeze maps into 9.6 - that seems
> more realistic given that we have a patch right now. Yes, it might end
> up being superflous churn, but it's rather localized. I think around
> we've
On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote:
> What design principle(s) have you been using to decide how autonomous
> transactions should behave?
I have to admit to a complete lack of principle. I'm quite frightened
of what this is going to need from the lock manager,
On Wed, Sep 9, 2015 at 2:17 AM, Haribabu Kommi wrote:
> And also regarding the number of workers (16) that is shown in the
> explain analyze plan are not actually allotted because the in my
> configuration i set the max_worker_process as 8 only. I feel the plan
> should
On 2015-09-09 10:46:47 -0400, Robert Haas wrote:
> Well, if you're filling ~1 clog page per second, you're doing ~1 fsync
> per second too. Or if you are not, then you are thrashing the
> progressively smaller and smaller number of clean slots ever-harder
> until no clean pages remain and you're
On 09/09/2015 10:27 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 09/05/2015 12:55 PM, Tom Lane wrote:
Or we could just give up and replace the counts by INT_MAX, forcing use
of the pager unless you've turned it off. All of those outputs are long
enough now that it's
On Wed, 9 Sep 2015 10:52:02 -0400
Bruce Momjian wrote:
> On Wed, Jun 17, 2015 at 07:58:21AM +0200, CPT wrote:
> > Hi all;
> >
> > We are running a multi-TB bioinformatics system on PostgreSQL and
> > use a denormalized schema in
> > places with a lot of tsvectors aggregated
On Wed, Sep 9, 2015 at 9:04 AM, Robert Haas wrote:
> On Sun, Sep 6, 2015 at 1:56 AM, Noah Misch wrote:
>> What design principle(s) have you been using to decide how autonomous
>> transactions should behave?
>
> I have to admit to a complete lack of
On Wed, Jul 22, 2015 at 9:56 PM, dinesh kumar wrote:
>> The real question is why the existing functionality in plpgsql isn't
>> sufficient. Somebody who wants a "log from SQL" function can easily
>> write a simple plpgsql function that does exactly what they want,
>>
On Wed, Sep 9, 2015 at 11:47 AM, Haribabu Kommi
wrote:
>
> With subquery, parallel scan is having some problem, please refer below.
>
>
> postgres=# explain analyze select * from test01 where kinkocord not in
> (select kinkocord from test02 where tenpocord = '001');
>
HI Robert,
On Wed, Sep 9, 2015 at 8:30 PM, Robert Haas wrote:
> On Wed, Jul 22, 2015 at 9:56 PM, dinesh kumar
> wrote:
> >> The real question is why the existing functionality in plpgsql isn't
> >> sufficient. Somebody who wants a "log from SQL"
On 09/09/2015 03:55 PM, Robert Haas wrote:
On Tue, Sep 8, 2015 at 5:02 PM, Tomas Vondra
wrote:
Also, I'm not sure what other places do you have in mind (could you list
some examples?) but I'd bet we limit the allocation to 1GB because of the
palloc() limit and not
On 09/08/2015 09:54 AM, Andrew Dunstan wrote:
On 09/05/2015 02:47 AM, Oskari Saarenmaa wrote:
There was a long thread about concatenating jsonb objects to each
other, but that discussion didn't touch concatenating other types.
Currently jsonb_concat always just returns the other argument
On Wed, Sep 9, 2015 at 10:35 AM, Tom Lane wrote:
> Robert Haas writes:
>> ... How often such a workload actually has to replace a *dirty* clog
>> buffer obviously depends on how often you checkpoint, but if you're
>> getting ~28k TPS you can completely
On Tue, Sep 8, 2015 at 11:31 PM, Amit Kapila wrote:
>> (3) posix_fadvise on Linux is a bad idea... the good news is that it
>> is not needed there:-) How good or bad an idea it is on other system
>> is an open question...
>
> I don't know what is the best way to
On Wed, Jun 17, 2015 at 07:58:21AM +0200, CPT wrote:
> Hi all;
>
> We are running a multi-TB bioinformatics system on PostgreSQL and
> use a denormalized schema in
> places with a lot of tsvectors aggregated together for centralized
> searching. This is
> very important to the performance of the
On Wed, Sep 9, 2015 at 8:09 PM, Robert Haas wrote:
>
> On Wed, Sep 9, 2015 at 2:17 AM, Haribabu Kommi
wrote:
> > And also regarding the number of workers (16) that is shown in the
> > explain analyze plan are not actually allotted because the in
On Wed, Sep 9, 2015 at 06:14:28PM +0300, Ildus Kurbangaliev wrote:
> On Wed, 9 Sep 2015 10:52:02 -0400
> Bruce Momjian wrote:
>
> > On Wed, Jun 17, 2015 at 07:58:21AM +0200, CPT wrote:
> > > Hi all;
> > >
> > > We are running a multi-TB bioinformatics system on PostgreSQL and
Hi All,
When there are several views defined on top of each other, are SELECTs
on views that do not specify a SORT order guaranteed to preserve the
cumulative sort order of the lower-level views ?
Is the answer true for any arbitrarily large set of layered views?
Is the answer the same if
On 9/9/15 12:03 PM, Oskari Saarenmaa wrote:
andrew=# select '[1]'::jsonb || '{"a":"b"}';
?column?
-
[1, {"a": "b"}]
It looks wrong, but I'm not sure what's right in that case. I think
it'd make sense to just restrict concatenation to object || object,
On 09/09/2015 03:03 PM, David Fetter wrote:
> Folks,
>
> While doing some research for the upcoming (UN)PIVOT proposal, I
> noticed that there were some hairy and no-longer-needed bits in the
> regression tests for tablefunc, which I have shaved off with the
> attached patch.
>
> What say?
Is
On Wed, Sep 9, 2015 at 11:07 AM, Amit Kapila wrote:
> On Wed, Sep 9, 2015 at 11:47 AM, Haribabu Kommi
> wrote:
>> With subquery, parallel scan is having some problem, please refer below.
>>
>> postgres=# explain analyze select * from test01
On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar wrote:
> I am admitting here that, I don’t know the real use case behind this
> proposal in our TODO list. I thought, having ereport wrapper at SQL level,
> gives a default debugging behavior for the end users, and this is the
On 9/9/15 5:27 PM, Robert Haas wrote:
Sure, it’s a clear fact that, we can implement this function with RAISE
>statements.
Given that, I suggest we just forget the whole thing.
Except that you can't use a variable to control the log level in a
plpgsql RAISE, so then you end up with a CASE
Folks,
While doing some research for the upcoming (UN)PIVOT proposal, I
noticed that there were some hairy and no-longer-needed bits in the
regression tests for tablefunc, which I have shaved off with the
attached patch.
What say?
Cheers,
David.
--
David Fetter
On 2015-09-09 18:27:51 -0400, Robert Haas wrote:
> On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar wrote:
> > Sure, it’s a clear fact that, we can implement this function with RAISE
> > statements.
>
> Given that, I suggest we just forget the whole thing.
I'm not
On Wed, Sep 9, 2015 at 7:53 PM, Charles Sheridan wrote:
> Hi All,
>
> When there are several views defined on top of each other, are SELECTs on
> views that do not specify a SORT order guaranteed to preserve the
> cumulative sort order of the lower-level views ?
>
> Is the
On 2015-09-04 23:35:42 +0100, Simon Riggs wrote:
> This looks OK. You saw that I was proposing to solve this problem a
> different way ("Summary of plans to avoid the annoyance of Freezing"),
> suggesting that we wait for a few CFs to see if a patch emerges for that -
> then fall back to this
On Thu, Sep 10, 2015 at 01:32:10AM +0200, Andres Freund wrote:
> On 2015-09-09 18:27:51 -0400, Robert Haas wrote:
> > On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar
> > wrote:
> > > Sure, it’s a clear fact that, we can implement this function
> > > with RAISE statements.
On 9/9/15 7:44 PM, David G. Johnston wrote:
On Wed, Sep 9, 2015 at 7:53 PM, Charles Sheridan >wrote:
Hi All,
When there are several views defined on top of each other, are
SELECTs on views that do not specify a SORT order guaranteed
On Thu, Sep 10, 2015 at 1:08 PM, Amit Kapila wrote:
> On Thu, Sep 10, 2015 at 9:29 AM, Fujii Masao wrote:
>>
>> On Thu, Sep 10, 2015 at 12:49 PM, Amit Kapila
>> wrote:
>> > On Wed, Sep 9, 2015 at 6:43 PM, Fujii Masao
On Wed, Sep 9, 2015 at 12:12 PM, Andres Freund wrote:
> On 2015-09-09 20:56:15 +0200, Fabien COELHO wrote:
> > As I wrote before, FreeBSD would be a good candidate because the
> > posix_fadvise seems much more reasonable than on Linux, and should be
> > profitable, so it
2015-09-10 2:47 GMT+02:00 David Fetter :
> On Thu, Sep 10, 2015 at 01:32:10AM +0200, Andres Freund wrote:
> > On 2015-09-09 18:27:51 -0400, Robert Haas wrote:
> > > On Wed, Sep 9, 2015 at 11:37 AM, dinesh kumar
> wrote:
> > > > Sure, it’s a clear fact
David Fetter writes:
> On Thu, Sep 10, 2015 at 01:32:10AM +0200, Andres Freund wrote:
>> I'm not convinced. Sure, it's easy, but I by now have written the
>> respective function dozens of times. Why should we force that on
>> everyone?
> +20 or so here, that being the number of
On Wed, Sep 9, 2015 at 6:43 PM, Fujii Masao wrote:
>
> On Fri, Sep 4, 2015 at 4:48 PM, Amit Kapila
wrote:
> >
> > You mean to say, just try renaming tablespace_map and don't display any
> > message whether that is successful or not-successful?
> >
On Thu, Sep 10, 2015 at 9:29 AM, Fujii Masao wrote:
>
> On Thu, Sep 10, 2015 at 12:49 PM, Amit Kapila
wrote:
> > On Wed, Sep 9, 2015 at 6:43 PM, Fujii Masao
wrote:
> >>
> >> On Fri, Sep 4, 2015 at 4:48 PM, Amit Kapila
Hi
2015-09-09 21:55 GMT+02:00 Alvaro Herrera :
> Pavel Stehule wrote:
>
> > I cannot to use current SplitIdentifierString because it is designed for
> > different purpose - and it cannot to separate non identifier part. But
> the
> > code is simple - and will be
On Wed, Sep 9, 2015 at 2:31 PM, Fabien COELHO wrote:
>
>
> Hello Amit,
>
>>> I think that we may conclude, on these run:
>>>
>>> (1) sorting seems not to harm performance, and may help a lot.
>>
>>
>> I agree with first part, but about helping a lot, I am not sure
>
>
> I'm
On Thu, Sep 10, 2015 at 12:49 PM, Amit Kapila wrote:
> On Wed, Sep 9, 2015 at 6:43 PM, Fujii Masao wrote:
>>
>> On Fri, Sep 4, 2015 at 4:48 PM, Amit Kapila
>> wrote:
>> >
>> > You mean to say, just try renaming
On Thu, Sep 10, 2015 at 4:16 AM, Robert Haas wrote:
>
> On Wed, Sep 9, 2015 at 11:07 AM, Amit Kapila
wrote:
> > On Wed, Sep 9, 2015 at 11:47 AM, Haribabu Kommi <
kommi.harib...@gmail.com>
> > wrote:
> >> With subquery, parallel scan is having some
On Wed, Sep 9, 2015 at 7:13 PM, Alexander Korotkov wrote:
> On Wed, Sep 9, 2015 at 9:01 AM, Michael Paquier wrote:
>> The code building the target history file is a duplicate of what is done
>> with the source. Perhaps we could refactor that as a single routine in
>> pg_rewind.c?
>
>
> Do you mean
Hi all,
timeline.h quotes that the end point of timeline history entry means
infinity when its value is 0. But that's not completely true, I think
that what is meant here is InvalidXLogRecPtr:
{
TimeLineID tli;
XLogRecPtr begin; /* inclusive */
-
HI, Sorry, it's my
misunderstand. I don't read seriously SlruSelectLRUPage before.
/* See if page already has a buffer assigned */
for (slotno = 0; slotno < shared->num_slots; slotno++)
{
if (shared->page_number[slotno] == pageno &&
shared->page_status[slotno] !=
Some stuff Salesforce has been doing turned up the fact that
RelationInitIndexAccessInfo is not safe against a relcache flush on
its target index. Specifically, the failure goes like this:
* RelationInitIndexAccessInfo loads up relation->rd_indextuple.
* Within one of the subsequent catalog
On 2015-09-09 20:56:15 +0200, Fabien COELHO wrote:
> As I wrote before, FreeBSD would be a good candidate because the
> posix_fadvise seems much more reasonable than on Linux, and should be
> profitable, so it would be a pity to remove it.
Why do you think it's different on fbsd? Also, why is it
(3) posix_fadvise on Linux is a bad idea... the good news is that it
is not needed there:-) How good or bad an idea it is on other system
is an open question...
I don't know what is the best way to verify that, if some body else has
access to such a m/c, please help to get that
Robert Haas wrote:
> I think the problem we should be trying to solve is: Given a set
> of server IPs, connect to one that is up.
>
> I believe this comes up in several different scenarios.
>
> Example #1: [single server; changing IP address gracefully]
>
> Example #2:
09.09.2015, 18:53, Andrew Dunstan kirjoitti:
On 09/08/2015 09:54 AM, Andrew Dunstan wrote:
On 09/05/2015 02:47 AM, Oskari Saarenmaa wrote:
There was a long thread about concatenating jsonb objects to each
other, but that discussion didn't touch concatenating other types.
Currently jsonb_concat
Michael Paquier writes:
> On Wed, Sep 9, 2015 at 4:12 AM, Robbie Harwood wrote:
>> Michael Paquier writes:
>> As promised, here's a V2 to address your issues with comments. I
>> haven't heard back on the issues you found in testing, so no other
>> changes are present.
It would replace what is currently an array.
It'd still be one afterwards.
[...]
extract/reinsert is actually O(1).
Hm, strange. I probably did not understood at all the heap structure
you're suggesting. No big deal.
[...] Why would a heap as I've described it require that?
Hmmm...
Hello Andres,
Wouldn't it be just as easy to put this logic into the checkpointing
code?
Not sure it would simplify anything, because the checkpointer currently
knows about buffers but flushing is about files, which are hidden from
view.
It'd not really simplify things, but it'd keep it
As I wrote before, FreeBSD would be a good candidate because the
posix_fadvise seems much more reasonable than on Linux, and should be
profitable, so it would be a pity to remove it.
Why do you think it's different on fbsd? Also, why is it unreasonable
that DONNEED removes stuff from the
Pavel Stehule wrote:
> I cannot to use current SplitIdentifierString because it is designed for
> different purpose - and it cannot to separate non identifier part. But the
> code is simple - and will be cleaned.
>
> postgres=# select * from parse_ident('"AHOJ".NAZDAR[]'::text);
>
On 2015-09-09 21:29:12 +0200, Fabien COELHO wrote:
> >Imagine a binaryheap.h style heap over a structure like (tablespaceid,
> >progress, progress_inc, nextbuf) where the comparator compares the progress.
>
> It would replace what is currently an array.
It'd still be one afterwards.
> The
On 2015-08-27 11:31:44 -0400, Tom Lane wrote:
> Needs a bit of copy-editing in places, but +1 overall.
Heres a slightly expanded version of this. I tried to do some of the
copy-editing, but I'm sure a look from a native speaker won't hurt.
Greetings,
Andres Freund
diff --git
81 matches
Mail list logo