On Tue, Sep 15, 2015 at 5:23 PM, Peter Eisentraut wrote:
> The only trick, as I remember, was that clients tend to prefer SSL
> automatically, which we probably don't want for Unix-domain sockets, so
> we'd need to tweak those settings a bit.
>
> The "old patch" referred to in that old thread wasn'
--progress-timestamp use Unix epoch timestamps in ms for progress
A quibble, but it isn't in ms, it is in seconds. The digits after the
decimal point give a precision to the ms level, but they don't change
the base unit.
Yes. The issue is mostly to keep the description under 80 column
Hi,
I found that codes about T_PrivGrantee was removed
by the following commit;
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=31eae6028eca4365e7165f5f33fee1ed0486aee0
but T_PrivGrantee is left in NodeTag in src/include/nodes/nodes.h.
Is it intended?
--
Yugo Nagata
--
Se
2015-09-16 2:41 GMT+02:00 Peter Eisentraut :
> On 9/11/15 6:25 AM, Pavel Stehule wrote:
> > new update of parse_ident function patch
>
> How would you actually use this?
>
> I know several people have spoken up that they could use this, but could
> you provide a few actual practical examples?
>
>
On Tue, Sep 8, 2015 at 2:35 PM, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
>
> Fixed patch is attached.
>
>
The commit of this patch seems to have created a bug in which updated
tuples can disappear from the index, while remaining in the table.
It looks like the bug depends on g
On 9/15/15 11:45 AM, Robert Haas wrote:
> On Tue, Sep 15, 2015 at 9:43 AM, Tom Lane wrote:
>> AFAICT from a quick look at its documentation, asciidoc can produce
>> either html or docbook output; so as soon as you want something other
>> than html output (in particular, PDF), you're back to relyin
On 2015-09-08 04:06, Michael Paquier wrote:
On Tue, Sep 8, 2015 at 10:44 AM, Michael Paquier
wrote:
Attached are as well changes for the documentation that I spotted in
earlier reviews but were not included in the last version sent by Petr
yesterday. Feel free to discard them if you think they
On 2015-09-03 15:03, Fujii Masao wrote:
On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas wrote:
There's no existing precedent for a feature that lets the standby be
different from the master *in any way*. So I don't see why we should
start here. I think the reasonable definition is that the GUC
c
On Wed, Sep 16, 2015 at 11:25 AM, Peter Eisentraut wrote:
> On 11/17/14 12:34 PM, Fujii Masao wrote:
>> Add --synchronous option to pg_receivexlog, for more reliable WAL writing.
>
> The last two sentences of this piece of documentation are a bit
> hand-wavy and hard to parse. Could you clarify t
On Wed, Sep 16, 2015 at 1:21 AM, Jesper Pedersen
wrote:
>
> On 09/15/2015 03:42 PM, Robert Haas wrote:
>>
>> I haven't really, just the email. But it seems like a neat concept.
>> So if I understand this correctly:
>>
>> 74.05% of spin delays are attributable to CLogControLock, 20.01% to
>> ProcA
On 11/17/14 12:34 PM, Fujii Masao wrote:
> Add --synchronous option to pg_receivexlog, for more reliable WAL writing.
The last two sentences of this piece of documentation are a bit
hand-wavy and hard to parse. Could you clarify this?
-S slotname
--slot=slotname
> The 9.5 release notes contain this promising but cryptic item:
>
> - Allow foreign data wrappers and custom scans to implement join
> pushdown (KaiGai Kohei)
>
> As phrased, this seems to mean, "it can be done, but we haven't done
> it". But there is no link to any documentation that explains
Hi,
While updating translations, I came across those almost similar sentences.
pg_controldata.c
273 printf(_("Latest checkpoint's oldestCommitTs: %u\n"),
274ControlFile.checkPointCopy.oldestCommitTs);
pg_resetxlog.c
668 printf(_("Latest checkpoint's oldest CommitTs: %u
>> I think so. We must be very careful updating the maps. Adding new
>> mapping data would cause less problem, but replacing existing mappings
>> will be definitely a big problem for users.
>
> Note that I'm not actually proposing to change the mappings, I just want
> to get the scripts into worki
The 9.5 release notes contain this promising but cryptic item:
- Allow foreign data wrappers and custom scans to implement join
pushdown (KaiGai Kohei)
As phrased, this seems to mean, "it can be done, but we haven't done
it". But there is no link to any documentation that explains how to do
this
On 9/11/15 6:25 AM, Pavel Stehule wrote:
> new update of parse_ident function patch
How would you actually use this?
I know several people have spoken up that they could use this, but could
you provide a few actual practical examples?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On 9/1/15 7:27 PM, Tatsuo Ishii wrote:
>> On Tue, Sep 1, 2015 at 5:13 AM, Peter Eisentraut wrote:
>>> So apparently, the
>>> CJK to Unicode mappings are still evolving and should be updated
>>> occasionally. Next steps would be to commit some or all of these
>>> differences after additional ver
On 9/2/15 7:15 PM, Andres Freund wrote:
>> Add a regression test suite for SSL support.
>>
>> It's not run by the global "check" or "installcheck" targets, because the
>> temporary installation it creates accepts TCP connections from any user
>> the same host, which is insecure.
>
On 16 September 2015 at 10:38, Rod Taylor wrote:
>
>
> On Tue, Sep 15, 2015 at 12:57 PM, Anastasia Lubennikova <
> a.lubennik...@postgrespro.ru> wrote:
>
>>
>> Proposal Clarification.
>> I see that discussion become too complicated. So, I'd like to clarify
>> what we are talking about.
>>
>> We a
On Tue, Sep 15, 2015 at 12:57 PM, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
>
> Proposal Clarification.
> I see that discussion become too complicated. So, I'd like to clarify
> what we are talking about.
>
> We are discussing 2 different improvements of index.
> The one is "pa
Tom Lane wrote:
> Michael Paquier writes:
> > On Tue, Sep 15, 2015 at 8:45 AM, Robert Haas wrote:
> >> I mean, I can't see that building a PDF of the documentation really
> >> has much value, and I don't know even what else we can build. Who in
> >> 2015 would use a PDF instead of HTML?
> >>
>
Michael Paquier writes:
> On Tue, Sep 15, 2015 at 8:45 AM, Robert Haas wrote:
>> I mean, I can't see that building a PDF of the documentation really
>> has much value, and I don't know even what else we can build. Who in
>> 2015 would use a PDF instead of HTML?
>>
>> (If there is somebody, that
On Tue, Sep 15, 2015 at 8:45 AM, Robert Haas wrote:
> I mean, I can't see that building a PDF of the documentation really
> has much value, and I don't know even what else we can build. Who in
> 2015 would use a PDF instead of HTML?
>
> (If there is somebody, that is fine. But I am curious who i
On Wed, Sep 9, 2015 at 6:03 AM, Greg Stark wrote:
> 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 r
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Sep 15, 2015 at 9:18 AM, Jim Nasby wrote:
> > Also, we've faced issues in the past with making catalog changes due to fear
> > of breaking user scripts. Instead of doubling down on that with RLS on top
> > of catalog tables, would it be better
On Tue, Sep 15, 2015 at 9:18 AM, Jim Nasby wrote:
> Also, we've faced issues in the past with making catalog changes due to fear
> of breaking user scripts. Instead of doubling down on that with RLS on top
> of catalog tables, would it be better to move the tables to a different
> schema, make the
On 09/15/2015 03:42 PM, Robert Haas wrote:
I haven't really, just the email. But it seems like a neat concept.
So if I understand this correctly:
74.05% of spin delays are attributable to CLogControLock, 20.01% to
ProcArrayLock, and 3.39% to XidGenLock. Incredibly, the queue length
reaches the
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> On 15 September 2015 at 15:22, Stephen Frost wrote:
> > Updated patch attached for review.
> >
> > Unless there are other concerns or issues raised, I'll push this later
> > today.
>
> Looks good to me.
Excellent, pushed!
> Thanks for do
On Tue, Sep 15, 2015 at 3:30 PM, Jesper Pedersen
wrote:
> X-axis is sort of "up in the air" with flame graphs -- similar call stacks
> are grouped together, and here it is the queue size.
>
> Y-axis is the lock queue size -- e.g. CLogControlLock is "max'ed" out, since
> there is a queue size of 80
> I could also see a potential gap in such approach. Specifically, I
> could see a case were there are two separate roles, one that is
> entrusted with defining the policies but not able to create/modify
> tables, and one with the opposite capability (I understand this to be
> a fairly common use-
On Wed, Sep 9, 2015 at 1:35 AM, Fabien COELHO wrote:
>
> 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 ge
On 09/15/2015 03:11 PM, Robert Haas wrote:
If there is an interest I'll add the patch to the next CommitFest.
Thanks for considering, and any feedback is most welcomed.
Seems neat, but I can't understand how to read the flame graphs.
X-axis is sort of "up in the air" with flame graphs -- si
On Tue, Sep 15, 2015 at 2:26 PM, Joe Conway wrote:
> On 09/15/2015 12:53 PM, Tom Lane wrote:
>> Joe Conway writes:
>>> There are use cases where row_security=force will be set in production
>>> environments, not only in testing.
>>
>> What cases, exactly, and is there another way to solve those p
On Tue, Sep 15, 2015 at 10:27 AM, Jesper Pedersen
wrote:
> Hi,
>
> I have been using the attached patch to look at how each LWLock relates to
> each other in various types of runs.
>
> The patch adds the following fields to a LWLOCK_STATS build:
>
> sh_acquire_max (int):
>
>The maximum shared
On Tue, Sep 15, 2015 at 2:44 PM, and...@anarazel.de wrote:
> On 2015-09-15 14:39:51 -0400, Robert Haas wrote:
>> We could, but since that would be strictly more annoying and less
>> flexible than what we've already got, why would we?
>
> I don't find the current approach of having to define tranch
On 2015-09-15 14:39:51 -0400, Robert Haas wrote:
> We could, but since that would be strictly more annoying and less
> flexible than what we've already got, why would we?
I don't find the current approach of having to define tranches in every
backend all that convenient. It also completely breaks
On Tue, Sep 15, 2015 at 12:44 PM, Ildus Kurbangaliev
wrote:
> On Mon, 14 Sep 2015 06:32:22 -0400
> Robert Haas wrote:
>
>> On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev
>> wrote:
>> > Yes, that is because I tried to go with current convention working
>> > with shmem in Postgres (there are
On 09/13/2015 10:29 AM, Kouhei Kaigai wrote:
> The attached one is the regression test fixup in v9.2.
> As we applied to the v9.3 or later, it replaces unconfined_t domain
> by the self defined sepgsql_regtest_superuser_t.
>
> Unfortunately, I found a bug to process SELECT INTO statement.
> Becaus
On 09/15/2015 12:53 PM, Tom Lane wrote:
> Joe Conway writes:
>> There are use cases where row_security=force will be set in production
>> environments, not only in testing.
>
> What cases, exactly, and is there another way to solve those problems?
> I concur with Noah's feeling that allowing secu
Joe Conway writes:
> On 09/15/2015 10:58 AM, Robert Haas wrote:
>> I can't argue with that, I suppose, but I think row_security=force is
>> a pretty useful convenience. If we must remove it, so be it, but I'd
>> be a little sad.
> There are use cases where row_security=force will be set in produ
[...]
Here is a v10 where I did that when it did not add too much code repetition
(eg I kept the shared branches for MIN & MAX and for the 3 RANDOM functions
so as to avoid large copy pastes).
Ooops, forgotten attachement.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/
Hello Kyotaro-san,
1.evalInt and evalDouble are mutually calling on single expr
node.
Indeed.
It looks simple and seems to work but could easily broken
to fall into infinite call and finally (in a moment) exceeds
stack depth.
The recursion is on the tree-structure of the expression, which
> That path is only taken if somebody else has already locked the buffer
> (e.g. BufferAlloc()). If you have contention in PinBuffer() your
> workload will be mostly cache resident and neither PinBuffer() nor
> UnpinBuffer() set BM_LOCKED.
Thanks. Now I understand everything. It might work.
We will
On Tue, Sep 15, 2015 at 7:12 AM, Alvaro Herrera
wrote:
>
> I think you need errcontext(), not errdetail(). The most important
> difference is that you can have multiple CONTEXT lines but only one
> DETAIL; I think if you attach a second errdetail(), the first one is
> overwritten.
>
>
Indeed, the
Kevin Grittner wrote:
> Alvaro Herrera wrote:
> > I would place it inside src/test/modules, so that buildfarm
> > runs it automatically; I'm not sure it will pick up things in
> > src/test.
>
> As it stands now, the test is getting run as part of `make
> check-world`, and it seems like src/test
On Tue, Sep 15, 2015 at 7:38 AM, Fujii Masao wrote:
> Thanks for the report and patch! Applied.
Thanks!
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Proposal Clarification.
I see that discussion become too complicated. So, I'd like to clarify
what we are talking about.
We are discussing 2 different improvements of index.
The one is "partially unique index" and the other "index with included
columns".
Let's look at example.
- We have a
On 2015-09-15 19:43:28 +0300, YUriy Zhuravlev wrote:
> On Tuesday 15 September 2015 16:50:44 Andres Freund wrote:
> > No, they can't in a a relevant manner. We hold the buffer header lock.
> I'm sorry, I did not notice of a LockBufHdr.
>
> In this embodiment, your approach seems to be very similar
On Mon, 14 Sep 2015 06:32:22 -0400
Robert Haas wrote:
> On Sun, Sep 13, 2015 at 5:05 PM, Ildus Kurbangaliev
> wrote:
> > Yes, that is because I tried to go with current convention working
> > with shmem in Postgres (there are one function that returns the
> > size and others that initialize that
On Tuesday 15 September 2015 16:50:44 Andres Freund wrote:
> No, they can't in a a relevant manner. We hold the buffer header lock.
I'm sorry, I did not notice of a LockBufHdr.
In this embodiment, your approach seems to be very similar to s_lock. Cycle in
PinBuffer behaves like s_lock.
In LockBuf
On 09/14/2015 04:24 PM, Andrew Dunstan wrote:
On 09/14/2015 03:42 PM, Teodor Sigaev wrote:
Currently, json_agg, jsonb_agg, json_object_agg and jsonb_object_agg do
type classification on their arguments on each call to the transition
function. This is quite unnecessary, as the argument types
On 09/15/2015 11:10 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch wrote:
>>> It also requires a DBA unwilling to
>>> furnish test accounts to custodians of sensitive data. With or without
>>> row_security=force, such a team is on the outer perimeter of
On 09/15/2015 10:58 AM, Robert Haas wrote:
> I can't argue with that, I suppose, but I think row_security=force is
> a pretty useful convenience. If we must remove it, so be it, but I'd
> be a little sad.
There are use cases where row_security=force will be set in production
environments, not onl
Robert Haas writes:
> On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch wrote:
>> It also requires a DBA unwilling to
>> furnish test accounts to custodians of sensitive data. With or without
>> row_security=force, such a team is on the outer perimeter of the audience
>> able
>> to benefit from RLS.
On 09/15/2015 11:54 AM, Tom Lane wrote:
Jan Wieck writes:
Would it be appropriate to use (Un)RegisterXactCallback() in case of
detecting excessive sequential scanning of that cache and remove all
invalid entries from it at that time?
Another idea is that it's not the size of the cache that's
Jan Wieck writes:
> Would it be appropriate to use (Un)RegisterXactCallback() in case of
> detecting excessive sequential scanning of that cache and remove all
> invalid entries from it at that time?
Don't see how unregistering the callback would help?
In any case, I'm -1 on this entire concep
On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch wrote:
>> ...but I'm not sure I like this, either. Without row_security=force,
>> it's hard for a table owner to test their policy, unless they have the
>> ability to assume some other user ID, which some won't. If someone
>> puts in place a policy whi
Hi Stephen
> On 15.09.2015, at 17:13, Stephen Frost wrote:
>
> Charles,
>
> * Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
>> Yes, that helped a lot! In the attachment now a single patch file
>> with all changes.
>
> I've pushed this fix now.
>
> Thanks!
>
> Stephen
Thanks, too
On Tue, Sep 15, 2015 at 9:56 AM, Andres Freund wrote:
> On 2015-09-15 08:07:57 -0500, Merlin Moncure wrote:
>> Also, I'm curious about your introduction of __builtin_expect()
>> macros. Did you measure any gain from them?
>
> I introduced them because I was bothered by the generated assembler ;)
On Tue, Sep 15, 2015 at 9:43 AM, Tom Lane wrote:
> AFAICT from a quick look at its documentation, asciidoc can produce
> either html or docbook output; so as soon as you want something other
> than html output (in particular, PDF), you're back to relying on the
> exact same creaky docbook toolchai
On 09/15/2015 10:58 AM, Tom Lane wrote:
I wrote:
Jan Wieck writes:
I'm able to reproduce that failure with CLOBBER_CACHE_ALWAYS and it
definitely is caused by this commit. Do you want to back it out for the
time being? Kevin is on vacation right now.
I'll take a look today, and either fix i
On 15 September 2015 at 15:22, Stephen Frost wrote:
> Updated patch attached for review.
>
> Unless there are other concerns or issues raised, I'll push this later
> today.
>
Looks good to me.
Thanks for doing all this.
Regards,
Dean
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Charles,
* Charles Clavadetscher (clavadetsc...@swisspug.org) wrote:
> Yes, that helped a lot! In the attachment now a single patch file
> with all changes.
I've pushed this fix now.
Thanks!
Stephen
signature.asc
Description: Digital signature
Jim Nasby writes:
> On 9/15/15 8:43 AM, Tom Lane wrote:
>> AFAICT from a quick look at its documentation, asciidoc can produce
>> either html or docbook output; so as soon as you want something other
>> than html output (in particular, PDF), you're back to relying on the
>> exact same creaky docbo
On 9/15/15 8:43 AM, Tom Lane wrote:
Jim Nasby writes:
I'm not sure SGML is the way to go anymore anyways. Asciidoc offers a
lot of what our SGML does in a much easier to support toolchain. It's
also natively supported by github, which makes it nice for others to
view the output (see [1] as an e
I wrote:
> Jan Wieck writes:
>> I'm able to reproduce that failure with CLOBBER_CACHE_ALWAYS and it
>> definitely is caused by this commit. Do you want to back it out for the
>> time being? Kevin is on vacation right now.
> I'll take a look today, and either fix it if I can find the problem
> q
On 2015-09-15 08:07:57 -0500, Merlin Moncure wrote:
> Are you confident this is faster across all workloads?
No. This is a proof of concept I just wrote & posted because I didn't
see the patch moving in the right direction. But I do think it can be
made faster in all relevant workloads.
> Pin/Unp
On 2015-09-15 12:51:24 +0300, YUriy Zhuravlev wrote:
> We had a version like your patch. But this is only half the work. Example:
> state = pg_atomic_read_u32(&buf->state);
> if ((state & BUF_REFCOUNT_MASK) == 0
> && (state & BUF_USAGECOUNT_MASK) == 0)
> After the first command somebody can ch
On 09/15/2015 09:51 AM, Tom Lane wrote:
Jan Wieck writes:
On 09/14/2015 09:56 AM, Tom Lane wrote:
Kevin Grittner writes:
Fix an O(N^2) problem in foreign key references.
Judging from the buildfarm, this patch is broken under
CLOBBER_CACHE_ALWAYS. See friarbird's results in particular.
I
On Thu, Sep 10, 2015 at 2:37 PM, Michael Paquier
wrote:
> 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;
>
Hello Thom,
>Okay, I've just tested this with a newly-loaded table (1,252,973 of jsonb
>data),
Thanks a lot!
>but after it's finished, I end up with this:
>json=# select * from pg_stat_vacuum_progress;
>-[ RECORD 1 ]---+---
>pid | 5569
>total_pages | 217941
>scan
Hi,
I have been using the attached patch to look at how each LWLock relates
to each other in various types of runs.
The patch adds the following fields to a LWLOCK_STATS build:
sh_acquire_max (int):
The maximum shared locks in series for the lock
ex_acquire_max (int):
The maximum e
On Fri, Sep 11, 2015 at 1:57 PM, Amit Kapila wrote:
> On Fri, Sep 11, 2015 at 10:10 AM, Fujii Masao wrote:
>>
>> So I added the object type, i.e., file in this case, to the errdetail
>> messages. Attached is the updated version of the patch.
>>
>> I also changed other log messages related to tabl
Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> A minor point -- this comment isn't quite right:
Fixed.
> because the policies that are fetched there are only used for
> add_security_quals(), not for add_with_check_options(). It might be
> cleaner if the 'if' statement that follows were
Jan Wieck writes:
> On 09/14/2015 09:56 AM, Tom Lane wrote:
>> Kevin Grittner writes:
>>> Fix an O(N^2) problem in foreign key references.
>> Judging from the buildfarm, this patch is broken under
>> CLOBBER_CACHE_ALWAYS. See friarbird's results in particular.
>> I might be too quick to finger
Rui Hai Jiang writes:
> Some Power CPU can switch the endianness mode.
> If one such CPU switches from big endian to little endian, could the
> configure script detect the real endianness mode?
It would detect whatever endianness you run it under.
No, we're not likely to worry about supporting
Jim Nasby writes:
> I'm not sure SGML is the way to go anymore anyways. Asciidoc offers a
> lot of what our SGML does in a much easier to support toolchain. It's
> also natively supported by github, which makes it nice for others to
> view the output (see [1] as an exmaple). If asciidoc isn't p
On 09/14/2015 09:56 AM, Tom Lane wrote:
Kevin Grittner writes:
Fix an O(N^2) problem in foreign key references.
Judging from the buildfarm, this patch is broken under
CLOBBER_CACHE_ALWAYS. See friarbird's results in particular.
I might be too quick to finger this patch, but nothing else
late
Hello,
Thank you Thomas and Sameer for checking the patch and giving your comments!
I will post an updated patch soon.
Regards,
Beena Emerson
On 9/14/15 7:38 PM, Haribabu Kommi wrote:
On Fri, Sep 11, 2015 at 7:50 AM, Joe Conway wrote:
On 09/01/2015 11:25 PM, Haribabu Kommi wrote:
If any user is granted any permissions on that object then that user
can view it's meta data of that object from the catalog tables.
To check the permissio
On Mon, Sep 14, 2015 at 9:06 PM, Andres Freund wrote:
> On 2015-09-14 17:41:42 +0200, Andres Freund wrote:
>> I pointed out how you can actually make this safely lock-free giving you
>> the interesting code.
>
> And here's an actual implementation of that approach. It's definitely
> work-in-progre
On 9/14/15 6:06 PM, Michael Paquier wrote:
On Tue, Sep 15, 2015 at 6:01 AM, Alvaro Herrera wrote:
I think the only way upstream Postgres could offer this is as a way to
build a separate "book", i.e. not a chapter/section within the main
book. I think it would require huge complications in doc/s
On 15 September 2015 at 23:51, Nicolas Barbier
wrote:
> 2015-09-15 David Rowley :
>
> > I'm also a bit confused where f3 comes in here. If it's UNIQUE on (f1,f2)
> > and we include f4. Where's f3?
>
> Columns f1, f2, f3 are in the internal nodes of the tree (i.e., they
> are used to find the ulti
Hello,
Continuing testing:
For pg_syncinfo.conf below an error is thrown.
{
"sync_info":
{
"quorum": 3,
"nodes":
2015-09-15 David Rowley :
> I'm also a bit confused where f3 comes in here. If it's UNIQUE on (f1,f2)
> and we include f4. Where's f3?
Columns f1, f2, f3 are in the internal nodes of the tree (i.e., they
are used to find the ultimate leaf nodes). f4 is only in the leaf
nodes. If f4 are typically
On 09/15/2015 12:45 PM, Anastasia Lubennikova wrote:
> 15.09.2015 12:11, Vik Fearing:
>> On 09/15/2015 10:57 AM, David Rowley wrote:
I agree, that form
> CREATE UNIQUE INDEX i ON t (f1, f2, f3) INCLUDE (f4)
> is clear. f4 will be used in row compare and actually planner will
> be a
Seems, final form is
CREATE INDEX idx ON tbl (f1, f2, f3) [UNIQUE ON (f1, f2)] [INCLUDE (f4)]
f1, f2, f3 are participated in index row comparence (btre, gist etc)
f1, f2 are participated in unique constrain and it gives warranty for
(f1, f2, f3[, f4]) uniqueness. Now supported by Btree only
f
On 15 September 2015 at 22:20, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
> Hm, I think that it would be quite clear to set it to zero for non-unique
> indexes.
> *(nunique == 0)* is equal to *(indisunique==false)*.
>
> But maybe I've missed some reason why we should to save *ind
15.09.2015 12:11, Vik Fearing:
On 09/15/2015 10:57 AM, David Rowley wrote:
I agree, that form
CREATE UNIQUE INDEX i ON t (f1, f2, f3) INCLUDE (f4)
is clear. f4 will be used in row compare and actually planner will be able
to use it as unique index (f1, f2, f3) with additional f4 or as
as unique
Hello,
I am using a foreign data wrapper where i get a portion of my data
pre-loaded , i.e I get a set of rows before hand . So now i want to run
multiple update queries on this loaded data , write the changes to file ,
load the next set and continue with updates again.
How should i try
15.09.2015 12:18, David Rowley:
On 12 September 2015 at 00:45, Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>>
wrote:
I've started work on a patch that allows to combine covering and
unique functionality.
Great to hear someone is working on this!
Thank you! It looks lik
Hello Jim
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Charles Clavadetscher
> Sent: Dienstag, 15. September 2015 07:35
> To: Jim Nasby ; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Attach comments to
On Saturday 12 September 2015 04:15:43 David Rowley wrote:
> I've run this on a single CPU server and don't see any speedup, so I assume
> I'm not getting enough contention.
> As soon as our 4 socket machine is free I'll try a pgbench run with that.
Excellent! Will wait.
> Just for fun, what's the
On Tuesday 15 September 2015 04:06:25 Andres Freund wrote:
> And here's an actual implementation of that approach. It's definitely
> work-in-progress and could easily be optimized further. Don't have any
> big machines to play around with right now tho.
Thanks. Interesting.
We had a version like
On Wed, Sep 9, 2015 at 10:03 PM, Greg Stark wrote:
> 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 rath
On 12 September 2015 at 00:45, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
> I've started work on a patch that allows to combine covering and unique
> functionality.
>
Great to hear someone is working on this!
> Next issue is pg_index changes.
> Now there's only a boolean flag
On 09/15/2015 10:57 AM, David Rowley wrote:
>> I agree, that form
>> > CREATE UNIQUE INDEX i ON t (f1, f2, f3) INCLUDE (f4)
>> > is clear. f4 will be used in row compare and actually planner will be able
>> > to use it as unique index (f1, f2, f3) with additional f4 or as
>> > as unique index (f1,
Hello,
Some Power CPU can switch the endianness mode.
If one such CPU switches from big endian to little endian, could the configure
script detect the real endianness mode?
Thanks,
Rui Hai
On Mon, Sep 14, 2015 at 7:27 PM, Pavel Stehule
wrote:
>
> 2015-09-14 18:46 GMT+02:00 Shulgin, Oleksandr <
> oleksandr.shul...@zalando.de>:
>
>>
>> I have a radical proposal to remove the need for locking: make the
>> CmdStatusSlot struct consist of a mere dsm_handle and move all the required
>> m
On 15 September 2015 at 18:16, Teodor Sigaev wrote:
> CREATE INDEX ... ON table (f1, f2, f3) UNIQUE(f1, f2) INCLUDE(f4);
>>
>
> I don't see an advantage this form. What is f3 column? just order? and f4
> will not be used for compare? At least now it requires additional checks
> that UNIQUE() fie
1 - 100 of 101 matches
Mail list logo