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
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 interrupt, and we keep waiting
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 add_paths_to_joinrel. For example, consider
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 various
>> lines in heapam.c, so it probably co
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 structures, it occurred to me that we may
want as well
On 09/05/2015 12:55 PM, Tom Lane wrote:
I wrote:
BTW, I noticed that the PageOutput line counts for psql's usage(),
slashUsage(), and helpVariables() were all three wrong, which I'm afraid
has been their usual state in the past too. Since commit 07c8651dd91d5aea
there's been a pretty easy way
Hi
I sending the path with little bit enhanced parser - it doesn't support
utf8 alpha in identifiers yet
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
**
On Tue, Sep 8, 2015 at 8:09 PM, Fabien COELHO wrote:
>
>
> Thanks a lot, again, for these tests!
>
> 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 based on
the tests
On Mon, Sep 7, 2015 at 11:47 AM, Tom Lane wrote:
> Michael Paquier writes:
>> statvfs is part of the POSIX spec and is "normally" present on modern
>> platforms (BSD, OSX, Linux and Solaris have it as far as I saw, still
>> there may be some strange platform without it).
>
> There are considerabl
On Wed, Sep 9, 2015 at 6:13 AM, Kevin Grittner wrote:
> Michael Paquier wrote:
> When I was working with Wisconsin Courts we needed something like
> this, and wrote it. It has been used on hundreds of clusters,
> 24/7, for years. I see that the last publicly posted updated was
> in 2008, but it l
On 08/31/2015 10:07 AM, Kevin Grittner wrote:
Kevin,
I've started to do a review on this patch but I am a bit confused with
some of what I am seeing.
The attached testcase fails I replace the cursor in your test case with
direct selects from the table.
I would have expected this to generat
On Wed, Sep 9, 2015 at 3:33 AM, Andres Freund wrote:
> On 2015-09-07 22:55:50 +0900, Michael Paquier wrote:
>> So, to summarize the state of this patch whose status is now "Waiting
>> on Author", we have the following possibilities:
>> 1) Keep the test as-is, as an independent test of src/test/mod
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
> because it added a reference to 'with_temp_install' but didn't actuall
On Wed, Sep 2, 2015 at 02:30:33PM -0300, Alvaro Herrera wrote:
> > I think we should rather add *one* test that does dump/restore over the
> > normal regression test database. Something similar to the pg_upgrade
> > tests. And then work at adding more content to the regression test
> > database -
Jim Nasby writes:
> On 9/5/15 3:50 PM, Tom Lane wrote:
>> Greg Stark writes:
>>> But that said, here's a tricksy patch that triggers an assertion
>>> failure if the expected_lines is wrong.
>> Hmm ... that would put a premium on the linecount always being exactly
>> right (for all callers, not j
On 9/5/15 3:50 PM, Tom Lane wrote:
Greg Stark writes:
But that said, here's a tricksy patch that triggers an assertion
failure if the expected_lines is wrong. I intended it to trigger in
the regression tests so it only checks if the pager is actually off.
It wouldn't be hard to make it always c
On Tue, Sep 8, 2015 at 1:56 AM, Alvaro Herrera
wrote:
> Thomas Munro wrote:
>
> > Thanks, good point. Here's a version that uses NULL via a macro ANY.
> > Aside from a few corrections it also now distinguishes between
> > TAIL_MATCHESn (common) and MATCHESn (rarely used for now), for example:
>
On 9/6/15 7: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 progress on 5) instead.
If 5) fails to bring a wo
On Tue, Sep 8, 2015 at 9:29 AM, Kevin Grittner wrote:
> I'm not saying we shouldn't have something like this; but we need a
> clear definition of that common problem we are solving. I don't
> think I've seen that yet. I've seen various spins on solutions
> described, from which I can infer vario
On 8 September 2015 at 22:35, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
>
> Fixed patch is attached.
>
> 08.09.2015 13:47, Teodor Sigaev:
>
>> BTW, I slightly modify your test to provide more stable results.
>>
>
> Thank you, I tried it, Results are nearly the same.
>
> Without
Fixed patch is attached.
08.09.2015 13:47, Teodor Sigaev:
BTW, I slightly modify your test to provide more stable results.
Thank you, I tried it, Results are nearly the same.
Without microvacuum
Time: 312,955 ms
Time: 264,597 ms
Time: 243,286 ms
Time: 243,679 ms
With microvacuum:
Time: 354,
* Andrew Dunstan (and...@dunslane.net) wrote:
> On 09/08/2015 02:58 PM, Stephen Frost wrote:
> >Would be great to get feedback on it as I'm no Makefile expert (it took
> >me far too long to run down what was happening and work out what seemed
> >like the right fix..).
>
>
> Seems OK to me from a
Heikki,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 09/04/2015 08:14 AM, Michael Paquier wrote:
> >Of course, that's not mandatory to fetch them. It is as well not worth
> >the complication to apply a filter to not fetch a portion of the
> >files, and I think that's why Heikki took the appr
On 09/08/2015 02:58 PM, 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
because it added a reference to 'with_temp_install' but didn't actually
define it.
The attached se
Michael Paquier wrote:
> There is currently no in-core function to query the amount of
> available and free space in a path of PGDATA, with something like that
> for example:
> SELECT * FROM pg_get_diskspace_info('pg_xlog');
> total_space | free_space
> -+
>4812
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-08-27 18:37:10 +0100, Dean Rasheed wrote:
> > Yes, I concur. It now needs an acquireLocksOnSubLinks_context with
> > for_execute = true, but otherwise it should work.
>
> Ok, I'll push that then, unless somebody else wants to do the honors.
Do
On 09/08/2015 08:44 PM, Robert Haas wrote:
On Tue, Sep 8, 2015 at 8:28 AM, Kouhei Kaigai wrote:
Hello KaiGai-san,
I've discovered a bug in the proposed patch - when resetting the hash
table after the first batch, it does this:
memset(hashtable->buckets, 0, sizeof(nbuckets * sizeof(HashJoinT
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 exactly what \x does
>
> The various definitions that I can see, such as
> http://dictionary.reference.com/bro
On 09/08/2015 04:21 PM, Peter Eisentraut wrote:
On 9/7/15 7:32 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
I already gave a use case that you dismissed in favour of a vague solution
that we don't actually have. You seem to be the only person objecting to
this proposal.
I think that use
Pavel Stehule wrote:
> rotate ~ sounds like transpose matrix, what is not true in this case.
The various definitions that I can see, such as
http://dictionary.reference.com/browse/rotate
make no mention of matrices. It applies to anything that
moves around a pivot or axis.
OTOH, the esta
2015-09-08 20:17 GMT+02:00 Corey Huinker :
>
>
> I would have immediate use for this. So often a function is written with a
> table name as a parameter and it's not immediately clear if the schema is
> to be parsed out of the string, prescribed, or a separate parameter...in
> which case the functio
I can never remember the syntax for setting index storage parameters. Is
it =, TO, or just a space between the parameter name and the setting?
This makes the tab completion more helpful, by providing the (mandatory)
equals sign.
Cheers,
Jeff
alter_index_tabcomplete_v1.patch
Description: Binar
On 9/7/15 7:21 PM, Andrew Dunstan wrote:
> I already gave a use case that you dismissed in favour of a vague
> solution that we don't actually have.
But that's also the only use case so far, which seems a little thin.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 9/7/15 7:32 PM, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>> I already gave a use case that you dismissed in favour of a vague solution
>> that we don't actually have. You seem to be the only person objecting to
>> this proposal.
>
> I think that use case would be better served by a comp
On Thu, Sep 3, 2015 at 11:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 2, 2015 at 1:47 PM, Tom Lane wrote:
>>> Offhand I think that the
>>> most likely way to build that text will be to examine the query's jointree
>>> to see where c,d,e appear in it. But in any case, that's a se
Michael Paquier writes:
> On Fri, Jul 3, 2015 at 3:22 AM, Robbie Harwood wrote:
>
>> Hello -hackers,
>>
>> As previously discussed on this list, I have coded up GSSAPI encryption
>> support. If it is easier for anyone, this code is also available for
>> viewing on my github:
>>
>> https://githu
* Andrew Dunstan (and...@dunslane.net) wrote:
> Improve logging of TAP tests.
[...]
This broke 'make check' for REL9_4_STABLE with --enable-tap-tests
because it added a reference to 'with_temp_install' but didn't actually
define it.
The attached seems to fix it.
Would be great to get feedback o
On Mon, Sep 7, 2015 at 1:33 PM, Ahsan Hadi wrote:
> I
>
> On Monday, September 7, 2015, Ashutosh Bapat
> wrote:
>>
>>
>>
>> On Sat, Sep 5, 2015 at 4:22 AM, Ozgun Erdogan wrote:
>>>
>>> Hey Robert,
>>>
Now the question is, where should the code that does all of this live?
postgres_fdw?
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 add_paths_to_joinrel. For example, consider:
>>
>> SELECT * FROM verysmall
On Tue, Sep 8, 2015 at 8:28 AM, Kouhei Kaigai wrote:
>> Hello KaiGai-san,
>>
>> I've discovered a bug in the proposed patch - when resetting the hash
>> table after the first batch, it does this:
>>
>> memset(hashtable->buckets, 0, sizeof(nbuckets * sizeof(HashJoinTuple)));
>>
>> The first 'sizeof
On 2015-09-08 19:52, Robert Haas wrote:
On Fri, Sep 4, 2015 at 6:52 PM, Ozgun Erdogan wrote:
For Citus, a second part of the question is as FDW writers. We implemented
cstore_fdw, json_fdw, and mongo_fdw, and these wrappers don't benefit from
even the simple join pushdown that doesn't require
On 2015-09-08 14:31:53 -0400, Robert Haas wrote:
> On Tue, Sep 8, 2015 at 2:19 PM, Andres Freund wrote:
> > On 2015-09-08 14:15:32 -0400, Robert Haas wrote:
> >> We could do that, but I'm not sure just calling LWLockNewTrancheId()
> >> for all of the tranches would be so bad either.
> >
> > To me
On 2015-09-07 22:55:50 +0900, Michael Paquier wrote:
> So, to summarize the state of this patch whose status is now "Waiting
> on Author", we have the following possibilities:
> 1) Keep the test as-is, as an independent test of src/test/modules.
I find that a bad option. A test that takes this lon
On Mon, Sep 7, 2015 at 9:34 AM, Alvaro Herrera wrote:
> Andres Freund wrote:
>> The buffer replacement algorithm for clog is rather stupid - I do wonder
>> where the cutoff is that it hurts.
>>
>> Could you perhaps try to create a testcase where xids are accessed that
>> are so far apart on averag
On Tue, Sep 8, 2015 at 2:19 PM, Andres Freund wrote:
> On 2015-09-08 14:15:32 -0400, Robert Haas wrote:
>> We could do that, but I'm not sure just calling LWLockNewTrancheId()
>> for all of the tranches would be so bad either.
>
> To me that seems either fragile or annoying to use. If all backends
On Tue, Sep 8, 2015 at 10:28 AM, Michael Paquier
wrote:
> On Tue, Sep 8, 2015 at 1:14 AM, Alexander Korotkov wrote:
> > On Thu, Aug 20, 2015 at 9:57 AM, Michael Paquier wrote:
> >> The code above looks correct to me when scanning the WAL history onwards
> >> though, which is what is done when ext
Hi,
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: 240.0 s, 31164.4 tps, lat 0.031 ms stddev 0.183
> progress: 241.0 s, 33243.3
On 08/09/2015 18:00, Alvaro Herrera wrote:
> Julien Rouhaud wrote:
>> Hi,
>>
>> Please find attached a v2 of the patch. See below for changes.
>
> Pushed after smallish tweaks. Please test to verify I didn't break
> anything.
>
I just tried with all the cases I could think of, everything works
On Sun, Sep 6, 2015 at 12:56 AM, Noah Misch wrote:
> My comments have flowed out of a principle that autonomous transactions shall
> have precisely the same semantics as using another backend via dblink.
That's what I thought, too. AT is syntax sugar for dblink approach.
Syntax and performance a
Shay Rojansky writes:
> Trying to execute the following query on PostgreSQL 9.4.4:
> select 'a' >= 'b' || 'c';
> Gives the result "falsec", implying that the precedence of the string
> concatenation operator is lower than the comparison operator. Changing the
> >= into = provides the result false,
On 2015-09-08 14:15:32 -0400, Robert Haas wrote:
> We could do that, but I'm not sure just calling LWLockNewTrancheId()
> for all of the tranches would be so bad either.
To me that seems either fragile or annoying to use. If all backends call
LWLockNewTrancheId() we need to a be sure the callbacks
On Tue, Sep 8, 2015 at 8:57 AM, Pavel Stehule
wrote:
>
>
> 2015-09-08 14:06 GMT+02:00 Robert Haas :
>
>> On Fri, Sep 4, 2015 at 12:24 AM, Pavel Stehule
>> wrote:
>> > The alghoritm for parsing identifiers is same - the differences are in a
>> > names of levels, and in ending symbols.
>> >
>> > I
On Tue, Sep 8, 2015 at 1:54 PM, Andres Freund wrote:
> On 2015-09-08 13:29:28 -0400, Robert Haas wrote:
>> I like this approach, though I think clearly it needs more performance
>> testing.
>
> Yea, obviously. I did run this on a slightly bigger machine yesterday
> and it gave consistent ~8% perf
On Tue, Sep 8, 2015 at 2:10 PM, David G. Johnston
wrote:
> On Tue, Sep 8, 2015 at 1:38 PM, Robert Haas wrote:
>> On Mon, Sep 7, 2015 at 5:08 PM, David G. Johnston
>> wrote:
>> > Given the role that psql performs I do think \rotate to be the least
>> > problematic choice; I concur that avoiding \
On Tue, Sep 8, 2015 at 1:38 PM, Robert Haas wrote:
> On Mon, Sep 7, 2015 at 5:08 PM, David G. Johnston
> wrote:
> > Given the role that psql performs I do think \rotate to be the least
> > problematic choice; I concur that avoiding \pivot is desirable due to
> SQL's
> > usage.
>
> I can't agree.
On 2015-09-08 13:29:28 -0400, Robert Haas wrote:
> I like this approach, though I think clearly it needs more performance
> testing.
Yea, obviously. I did run this on a slightly bigger machine yesterday
and it gave consistent ~8% performance improvements.
> The method of determining the tranche
On Fri, Sep 4, 2015 at 6:52 PM, Ozgun Erdogan wrote:
> Distributed shuffles (Map/Reduce) are hard. When we looked at using FDWs for
> pg_shard, we thought that Map/Reduce would require a comprehensive revamp of
> the APIs.
Well, so you've said. But what kind of API do you want to see?
Taking con
On Sun, Sep 6, 2015 at 3:34 PM, Joe Conway wrote:
> On 09/02/2015 02:54 PM, Alvaro Herrera wrote:
>> Josh Berkus wrote:
>>> On 09/02/2015 02:34 PM, Alvaro Herrera wrote:
I think trying to duplicate the exact strings isn't too nice an
interface.
>>>
>>> Well, for pg_controldata, no, but w
On Mon, Sep 7, 2015 at 5:08 PM, David G. Johnston
wrote:
> Given the role that psql performs I do think \rotate to be the least
> problematic choice; I concur that avoiding \pivot is desirable due to SQL's
> usage.
I can't agree. Rotating a matrix has a well-defined meaning, and this
does someth
On Mon, Sep 7, 2015 at 3:32 PM, Teodor Sigaev wrote:
> Petr Jelinek wrote:
>>
>> On 2015-09-07 17:41, Teodor Sigaev wrote:
>>>
>>> Some notices:
>>>
>>> 1) create-am.3.patch.gz
>>>As I understand, you didn't add schema name to access method. Why?
>>> Suppose, if we implement SQL-like interface
On Wed, Sep 9, 2015 at 2:00 AM, Teodor Sigaev wrote:
>> I assume it's an oversight. It was originally added in
>
> Agree, it seems so
So fixed. Thanks!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On Mon, Sep 7, 2015 at 1:59 PM, Andres Freund wrote:
> On 2015-09-06 15:28:40 +0200, Andres Freund wrote:
>> Hm. I found that the buffer content lwlocks can actually also be a
>> significant source of contention - I'm not sure reducing padding for
>> those is going to be particularly nice. I think
On Mon, Sep 7, 2015 at 11:18 AM, Masahiko Sawada wrote:
> On Sat, Sep 5, 2015 at 7:35 AM, Simon Riggs wrote:
>> On 3 September 2015 at 18:23, Masahiko Sawada wrote:
>>> The previous patch lacks some files for regression test.
>>> Attached fixed v12 patch.
>>
>> This looks OK. You saw that I was
On Mon, Sep 7, 2015 at 7:33 AM, Ildus Kurbangaliev
wrote:
>> > Ildus, could you please review Amit & Robert's patch?
>> [1] -
>> http://www.postgresql.org/message-id/caa4ek1kdec1tm5ya9gkv85vtn4qqsrxzkjru-tu70g_tl1x...@mail.gmail.com
> About [1] and [2]. They are slightly conflicting, but if [1] is
I assume it's an oversight. It was originally added in
Agree, it seems so
8a3631f8d86cdd9b07c577d6e213b1fc824db255, the commit that originally
added GIN. Documentation was added later that year in
0ca9907ce443c58532f1c09e716b7d9cad9039a5. Why would we intentionally
document it but leave it o
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 interrupt, and we keep waiting
> forever in shm_mq_receive(). We could add a timeout par
Hi hackers.
Trying to execute the following query on PostgreSQL 9.4.4:
select 'a' >= 'b' || 'c';
Gives the result "falsec", implying that the precedence of the string
concatenation operator is lower than the comparison operator. Changing the
>= into = provides the result false, which is less sur
Andres Freund wrote:
> On 2015-09-08 07:06:04 +0200, Pavel Stehule wrote:
> > 2015-09-07 21:44 GMT+02:00 Andres Freund :
> > > The spellings for boolean values were a relatively small subset of what
> > > the backend accepts - it's now on,off,true,false,yes,no,1,0. I'm not
> > > sure whether that's
On Fri, Sep 4, 2015 at 4:48 AM, Fujii Masao wrote:
> My client found that gin_fuzzy_search_limit is not included in
> postgresql.conf.sample. Is this intentional? Or oversight?
I assume it's an oversight. It was originally added in
8a3631f8d86cdd9b07c577d6e213b1fc824db255, the commit that origin
On 2015-09-08 07:06:04 +0200, Pavel Stehule wrote:
> 2015-09-07 21:44 GMT+02:00 Andres Freund :
> > The spellings for boolean values were a relatively small subset of what
> > the backend accepts - it's now on,off,true,false,yes,no,1,0. I'm not
> > sure whether that's a good idea. Comments?
> >
>
On Tue, Sep 8, 2015 at 4:30 PM, Tom Lane wrote:
> As an example of potentially-more-useful aids, I'm wondering about
> tracking the high-water memory consumption of each memory context.
> (This probably wouldn't be terribly expensive if it were done at the
> granularity of malloc requests rather t
On Mon, Sep 7, 2015 at 11:25 PM, Fabien COELHO wrote:
>
> Use milliseconds for consistency with the '%n' log_prefix patch currently
>>> submitted by Tomas Vondra in the CF.
>>>
>>> sh> ./pgbench -P 1 -N -T 100 -c 2
>>> starting vacuum...end.
>>> progress: 1.0 s, 546.0 tps, lat 3.619 ms stdd
Julien Rouhaud wrote:
> Hi,
>
> Please find attached a v2 of the patch. See below for changes.
Pushed after smallish tweaks. Please test to verify I didn't break
anything.
(It's a pity that we can't add a regression test with a value other than
0.)
--
Álvaro Herrerahttp://www.
On 8 September 2015 at 14:44, Nathan Wagner wrote:
> I have two patches to make the geqo initialization and mutation
> slightly better.
>
> The first adjusts the mutation swaps to avoid having to re-pick
> ties. The second changes the initialization and shuffling algorithm
> for the gene array t
Rajeev rastogi writes:
> In our customer environment as well as during development, we have observed
> that many time we need to get details of memory used by each contexts in
> order to analyze the memory consumption/leak.
> So I would like to propose one contrib function interface, which will
On 09/08/2015 10:48 AM, Teodor Sigaev wrote:
This looks correct. Barring objection I'll apply this shortly.
+1 Seems correct. Should we backpatch that?
Yes, certainly.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On 8 September 2015 at 15:48, Teodor Sigaev wrote:
> This looks correct. Barring objection I'll apply this shortly.
>>
>
> +1 Seems correct. Should we backpatch that?
>
Yes, this needs correcting in 9.5 where it has been introduced.
Thom
This looks correct. Barring objection I'll apply this shortly.
+1 Seems correct. Should we backpatch that?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailin
Hello Amit,
I have done some tests with both the patches(sort+flush) and below
are results:
Thanks a lot for these runs on this great harware!
Test - 1 (Data Fits in shared_buffers)
Rounded for easier comparison:
flush/sort
off off: 27480.4 ± 12791.1 [ 0, 16009, 32109, 37629, 51671
Michael Paquier wrote:
> On Tue, Sep 8, 2015 at 9:32 AM, Alvaro Herrera wrote:
> > Michael Paquier wrote:
> > I made a couple extra cleanups to the patch, namely: do not call
> > CreateTemplateTupleDesc() just to discard the resulting tupdesc with a
> > subsequent get_call_result_type(); and do not
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 if one
of arguments is considered empty. This cau
I have two patches to make the geqo initialization and mutation
slightly better.
The first adjusts the mutation swaps to avoid having to re-pick
ties. The second changes the initialization and shuffling algorithm
for the gene array to use an in-place Fisher-Yates shuffling
algorithm.
Diffs again
HI, this is the test case:Use stap track pg_clog/* fsync call.
[root@digoal ~]# cat trc.stp
global f_start[99]
probe
process("/opt/pgsql/bin/postgres").function("SlruPhysicalWritePage@/opt/soft_bak/postgresql-9.4.4/src/backend/access/transam/slru.c").call
{
f_start[execname(), pid(),
Bruce Momjian wrote:
> It is annoying for less capable database to say they have high
> availability when that just involves having a client library that
> can connect to multiple hosts.
This sounds like the "But all the *other* kids are doing it!"
argument, which comes up often. We generally r
On Tue, Sep 8, 2015 at 9:32 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
> I made a couple extra cleanups to the patch, namely: do not call
> CreateTemplateTupleDesc() just to discard the resulting tupdesc with a
> subsequent get_call_result_type(); and do not write a \0 to the
> BIO_s_mem, a
2015-09-08 14:06 GMT+02:00 Robert Haas :
> On Fri, Sep 4, 2015 at 12:24 AM, Pavel Stehule
> wrote:
> > The alghoritm for parsing identifiers is same - the differences are in a
> > names of levels, and in ending symbols.
> >
> > I don't would to write totally generic parser - more without access t
In our customer environment as well as during development, we have observed
that many time we need to get details of memory used by each contexts in order
to analyze the memory consumption/leak.
So I would like to propose one contrib function interface, which will dump the
whole memory context i
Jan Wieck wrote:
> The problem is a cache introduced in commit 45ba4247 that improves
That's a bit off; 45ba424f seems to be what you mean.
> foreign key lookups during bulk updates when the FK value does not
> change. When restoring a schema dump from a database with many (say
> 100,000) forei
> Hello KaiGai-san,
>
> I've discovered a bug in the proposed patch - when resetting the hash
> table after the first batch, it does this:
>
> memset(hashtable->buckets, 0, sizeof(nbuckets * sizeof(HashJoinTuple)));
>
> The first 'sizeof' is bogus, so this only zeroes the first 8 bytes of
> the
On Fri, Sep 4, 2015 at 12:24 AM, Pavel Stehule wrote:
> The alghoritm for parsing identifiers is same - the differences are in a
> names of levels, and in ending symbols.
>
> I don't would to write totally generic parser - more without access to
> system catalog or without external hint, you canno
On Mon, Sep 7, 2015 at 7:04 PM, Alvaro Herrera
wrote:
>
> Andres Freund wrote:
>
> > The buffer replacement algorithm for clog is rather stupid - I do wonder
> > where the cutoff is that it hurts.
> >
> > Could you perhaps try to create a testcase where xids are accessed that
> > are so far apart
On Sat, Sep 5, 2015 at 12:26 PM, Fabien COELHO wrote:
>
> I would be curious whether flushing helps, though.
>>>
>>> Yes, me too. I think we should try to reach on consensus for exact
>>> scenarios and configuration where this patch('es) can give benefit or we
>>> want to verify if there is a
BTW, I slightly modify your test to provide more stable results.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
drop table test;
CREATE TABLE test (box box);
alter table test set (autovacu
Something goes wrong...
gist.c:1465:5: warning: unused variable 'minoff' [-Wunused-variable]
minoff,
gistget.c:37:1: warning: unused function 'gistkillitems' [-Wunused-function]
gistkillitems(IndexScanDesc scan)
Without microvacuum. All 'select' queries are execu
On Tue, Sep 8, 2015 at 6:58 AM, Pavel Stehule
wrote:
>>
>> But you will still lock on the slots list to find an unused one. How is
that substantially different from what I'm doing?
>
> It is not necessary - you can use similar technique to what it does
PGPROC. I am sending "lock free" demo.
>
> I
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 add_paths_to_joinrel. For example, consider:
SELECT * FROM verysmall v JOIN (bigft1 FULL JOIN bigft2 ON bigft1.x =
bigft2.x) ON v.q = big
On 2015/09/02 23:30, Tom Lane wrote:
> Etsuro Fujita writes:
>> On 2015/08/01 23:25, Tom Lane wrote:
>>> In my vision you probably really only want one call per build_join_rel
>>> event (that is, per construction of a new RelOptInfo), not per
>>> make_join_rel event.
>> I'd vote for hooking at st
Am 07.09.2015 um 16:40 schrieb Tom Lane:
Andrew Dunstan writes:
On 09/07/2015 09:28 AM, Alvaro Herrera wrote:
This seems pretty much the same as a junk attribute, if I understand you
correctly. I suggest given a look at how those work.
Is that actually documented anywhere much?
I don't
On Sun, Sep 6, 2015 at 7:34 AM, 周正中(德歌) wrote:
>
> >On 2015-09-10 19:39:59 +0800, 张广舟(明虚) wrote:
> >> We found there is a fsync call when CLOG buffer
>
> >> is written out in SlruPhysicalWritePage(). It is often called when a
> >> backend
> >> needs to check transaction status with SimpleLruRead
On Tue, Sep 8, 2015 at 1:14 AM, Alexander Korotkov wrote:
> On Thu, Aug 20, 2015 at 9:57 AM, Michael Paquier wrote:
>> The code above looks correct to me when scanning the WAL history onwards
>> though, which is what is done when extracting the page map, but not
>> backwards when we try to find the
100 matches
Mail list logo
