On 3 November 2015 at 02:58, Jim Nasby wrote:
> On 11/2/15 8:36 AM, Craig Ringer wrote:
>
>> Here's the protocol documentation discussed in the README. It's
>> asciidoc at the moment, so it can be formatted into something with
>> readable tables.
>>
>
> Is this by chance up on github? It'd be eas
2015-11-12 1:35 GMT+01:00 David G. Johnston :
> On Wed, Nov 11, 2015 at 7:01 AM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>> It seems to me that the documentation should specify that when -C is
>> used with -1 each individual series of commands is executed within a
>> transaction bl
On Thu, Nov 12, 2015 at 9:04 AM, Michael Paquier wrote:
> On Thu, Nov 12, 2015 at 12:41 AM, Nikolay Shaplov wrote:
>> I still have an opinion that documentation should be more verbose, than your
>> version, but I can accept your version.
>
> I am not sure that's necessary, pageinspect is for develo
Hello,
> > I really don't see why you're fighting on this point. Making this a
> > generic feature will require only a few extra lines of code for FDW
> > authors. If this were going to cause some great inconvenience for FDW
> > authors, then I'd agree it isn't worth it. But I see zero evidenc
On Thu, Nov 12, 2015 at 9:35 AM, David G. Johnston
wrote:
> On Wed, Nov 11, 2015 at 7:01 AM, Michael Paquier
> wrote:
>>
>> It seems to me that the documentation should specify that when -C is
>> used with -1 each individual series of commands is executed within a
>> transaction block.
>
> In sum
> -Original Message-
> From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp]
> Sent: Thursday, November 12, 2015 2:54 PM
> To: Robert Haas
> Cc: Kaigai Kouhei(海外 浩平); Tom Lane; Kyotaro HORIGUCHI;
> pgsql-hackers@postgresql.org; Shigeru Hanada
> Subject: Re: [HACKERS] Foreign join pus
On Thu, Nov 12, 2015 at 9:06 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Thu, Nov 12, 2015 at 6:27 AM, Alvaro Herrera
>> wrote:
>>> I think you're remembering this:
>>> http://www.postgresql.org/message-id/20150402205713.gb22...@eldon.alvh.no-ip.org
>
>> Right. Thanks. Do you think we'd
On 2015/11/12 2:53, Robert Haas wrote:
On Sun, Nov 8, 2015 at 11:13 PM, Etsuro Fujita
wrote:
To test this change, I think we should update the postgres_fdw patch so as
to add the RecheckForeignScan.
Having said that, as I said previously, I don't see much value in adding the
callback routine,
On 2015/11/12 14:09, Kouhei Kaigai wrote:
> I'm now designing the parallel feature of Append...
>
> Here is one challenge. How do we determine whether each sub-plan
> allows execution in the background worker context?
>
> The commit f0661c4e8c44c0ec7acd4ea7c82e85b265447398 added
> 'parallel_aware
I'm now designing the parallel feature of Append...
Here is one challenge. How do we determine whether each sub-plan
allows execution in the background worker context?
The commit f0661c4e8c44c0ec7acd4ea7c82e85b265447398 added
'parallel_aware' flag on Path and Plan structure.
It tells us whether t
> Robert Haas writes:
> > On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote:
> >> Just better serialization doesn't actually help all that much. Being
> >> able to conveniently access data directly, i.e. as fields in a struct,
> >> makes code rather more readable. And in many cases more
> >> e
> On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote:
> > On 2015-11-11 14:59:33 -0500, Robert Haas wrote:
> >> I don't see this as being a particularly good idea. The same issue
> >> exists for FDWs, and we're just living with it in that case.
> >
> > It's absolutely horrible there. I don't se
New version attached, merging recent changes.
--
Thomas Munro
http://www.enterprisedb.com
tab-complete-v8.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
On 12/11/15 13:52, Greg Stark wrote:
On Wed, Nov 11, 2015 at 6:57 PM, Gavin Flower
wrote:
Don't you realize that 400MB is over 4 million of the old 100Kb floppy
disks, and even with the new big 1.44MB 3.5 " disks, you'd need about 280!!!
Don't be silly. It's only four thousand 100Kb floppies.
On 2015/11/12 4:26, Robert Haas wrote:
> On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule
> wrote:
>> I have a first query
>>
>> I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are
>> differen
>
> Hmm, I see I was right about people finding more bugs once this was
> committed.
On Wed, Nov 11, 2015 at 6:57 PM, Gavin Flower
wrote:
> Don't you realize that 400MB is over 4 million of the old 100Kb floppy
> disks, and even with the new big 1.44MB 3.5 " disks, you'd need about 280!!!
Don't be silly. It's only four thousand 100Kb floppies.
--
greg
--
Sent via pgsql-hack
On Thu, Nov 12, 2015 at 12:10 AM, Ants Aasma wrote:
> On Wed, Nov 11, 2015 at 11:22 AM, Thomas Munro
> wrote:
> > On Wed, Nov 11, 2015 at 9:42 PM, Heikki Linnakangas
> wrote:
> >> On 11/11/2015 10:23 AM, Simon Riggs wrote:
> >>> Thanks for working on this issue.
> >>
> >> +1.
>
> +1. I have see
On Wed, Nov 4, 2015 at 6:30 PM, David Rowley
wrote:
>> Have you thought about *just* having an int64 pg_ltostr()? Are you
>> aware of an appreciable overhead from having int32 callers just rely
>> on a promotion to int64?
>
> I'd not thought of that. It would certainly add unnecessary overhead on
On Wed, Nov 11, 2015 at 7:01 AM, Michael Paquier
wrote:
> It seems to me that the documentation should specify that when -C is
> used with -1 each individual series of commands is executed within a
> transaction block.
In summary:
Default (Not Single + Auto-Commit): One Transactions per parse
Michael Paquier writes:
> On Thu, Nov 12, 2015 at 6:27 AM, Alvaro Herrera
> wrote:
>> I think you're remembering this:
>> http://www.postgresql.org/message-id/20150402205713.gb22...@eldon.alvh.no-ip.org
> Right. Thanks. Do you think we'd still want a patch to improve that?
Give it a try if you
On Thu, Nov 12, 2015 at 12:41 AM, Nikolay Shaplov
wrote:
> В письме от 28 октября 2015 16:57:36 пользователь Michael Paquier написал:
>> On Sat, Oct 17, 2015 at 1:48 AM, Michael Paquier wrote:
>> > On Sat, Oct 17, 2015 at 5:15 AM, Nikolay Shaplov wrote:
>> >> Or it's ready to commit, and just not
On Thu, Nov 12, 2015 at 6:27 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> I recall that we had some talks about grouping all the relopts into a
>> single documentation section, perhaps not having one is at the origin
>> of the confusion?
>
> I think you're remembering this:
> http://www
On 11 November 2015 at 19:51, Thom Brown wrote:
> On 11 November 2015 at 19:26, Robert Haas wrote:
>> On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule
>> wrote:
>>> I have a first query
>>>
>>> I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are
>>> differen
>>
>> Hmm, I see
Michael Paquier wrote:
> I recall that we had some talks about grouping all the relopts into a
> single documentation section, perhaps not having one is at the origin
> of the confusion?
I think you're remembering this:
http://www.postgresql.org/message-id/20150402205713.gb22...@eldon.alvh.no-ip.
Tom Lane wrote:
> Michael Paquier writes:
> > On Wed, Nov 11, 2015 at 12:07 AM, Tom Lane wrote:
> >> Should it read "Overrides log_autovacuum_min_duration for autovacuum
> >> operations on this specific table or toast table"?
>
> > The same applied for all the other autovacuum and autoanalyze
>
Robert Haas writes:
> On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote:
>> Just better serialization doesn't actually help all that much. Being
>> able to conveniently access data directly, i.e. as fields in a struct,
>> makes code rather more readable. And in many cases more
>> efficient. Ha
Michael Paquier writes:
> On Wed, Nov 11, 2015 at 12:07 AM, Tom Lane wrote:
>> Should it read "Overrides log_autovacuum_min_duration for autovacuum
>> operations on this specific table or toast table"?
> The same applied for all the other autovacuum and autoanalyze
> parameters. Do you think tha
On Wed, Nov 11, 2015 at 3:29 PM, Andres Freund wrote:
> On 2015-11-11 14:59:33 -0500, Robert Haas wrote:
>> I don't see this as being a particularly good idea. The same issue
>> exists for FDWs, and we're just living with it in that case.
>
> It's absolutely horrible there. I don't see why that's
On 2015-11-11 14:59:33 -0500, Robert Haas wrote:
> I don't see this as being a particularly good idea. The same issue
> exists for FDWs, and we're just living with it in that case.
It's absolutely horrible there. I don't see why that's a justification
for much. To deal with the lack of extensibl
On Mon, Nov 9, 2015 at 10:26 PM, Kouhei Kaigai wrote:
> It is a relevant topic of readfuncs support for custom-scan.
>
> Unlike CustomPath and CustomScanState, we don't allow custom-scan
> provider to define own and larger structure that embeds CustomScan
> at head of the structure, to support cop
On 11 November 2015 at 19:26, Robert Haas wrote:
> On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule
> wrote:
>> I have a first query
>>
>> I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are
>> differen
>
> Hmm, I see I was right about people finding more bugs once this was
>
2015-11-11 20:26 GMT+01:00 Robert Haas :
> On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule
> wrote:
> > I have a first query
> >
> > I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are
> > differen
>
> Hmm, I see I was right about people finding more bugs once this was
> commi
On Wed, Nov 11, 2015 at 12:59 PM, Pavel Stehule wrote:
> I have a first query
>
> I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are
> differen
Hmm, I see I was right about people finding more bugs once this was
committed. That didn't take long.
There's supposed to be code
Andrew Dunstan writes:
> On 11/11/2015 12:34 PM, Tom Lane wrote:
>> I was thinking more of removing the "missing" script and associated logic
>> entirely, rather than making PGXS a special case. I think we should do
>> our best to minimize differences between behaviors in core builds and
>> PGXS
On 11/11/15 4:22 AM, Thomas Munro wrote:
> My thinking was that the reason for wanting to load balance over a set
> of hot standbys is because you have a very read-heavy workload, so it
> makes sense to tax the writers and leave the many dominant readers
> unburdened, so (3) should be better than (
On 11/11/2015 12:34 PM, Tom Lane wrote:
Peter Eisentraut writes:
On 11/2/15 4:07 PM, Tom Lane wrote:
I wonder how much we need that script at all though. If, say, configure
doesn't find bison, what's so wrong with just defining BISON=bison and
letting the usual shell "bison: command not fou
Peter Eisentraut wrote:
> On 11/10/15 12:03 PM, Alvaro Herrera wrote:
> > Peter Eisentraut wrote:
> >> Translation updates
> >>
> >> Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
> >> Source-Git-Hash: cd263526676705b4a8a3a708c9842461c4a2bcc3
> >
> > Hi Peter,
> >
> > Wou
On 11/11/2015 11:31 AM, Tom Lane wrote:
> After sleeping on it, the best compromise I can think of is to add an
> "Assert(false)" after the WARNING report for the shared-catalogs case.
> This will make the failure un-missable in any development build, while
> not breaking production builds' ability
On 12/11/15 02:07, Craig Ringer wrote:
On 11 November 2015 at 16:02, Torsten Zühlsdorff
mailto:mailingli...@toco-domains.de>>
wrote:
From my experience most databases are just tpo small. Their
operations finish before there can be a deadlock. Same for race
conditions - most deve
Peter Eisentraut writes:
> On 11/11/15 12:08 PM, Tom Lane wrote:
>> we're failing to build against Python 3.5 because the python guys
>> have randomly changed some error message texts, again.
> This has already been fixed in the 9.5.
Well, that's nice, but surely it should have been back-patched
Peter Eisentraut wrote:
> On 11/11/15 12:34 PM, Tom Lane wrote:
> > I was thinking more of removing the "missing" script and associated logic
> > entirely, rather than making PGXS a special case. I think we should do
> > our best to minimize differences between behaviors in core builds and
> > PGX
On Wednesday 11 November 2015 17:29:31 you wrote:
> In this case the syntax is major issue. Any language should not to have any
> possible feature on the world.
I am about omitted boundaries. It almost does not change the syntax and with
nothing conflicts.
Thanks.
--
YUriy Zhuravlev
Postgres Pr
On 11/11/15 12:34 PM, Tom Lane wrote:
> I was thinking more of removing the "missing" script and associated logic
> entirely, rather than making PGXS a special case. I think we should do
> our best to minimize differences between behaviors in core builds and
> PGXS builds, if only because we don't
On 11/11/15 12:08 PM, Tom Lane wrote:
> we're failing to build against Python 3.5 because the python guys
> have randomly changed some error message texts, again.
This has already been fixed in the 9.5.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
2015-11-11 19:03 GMT+01:00 Thom Brown :
> On 11 November 2015 at 17:59, Pavel Stehule
> wrote:
> > Hi
> >
> > I have a first query
> >
> > I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are
> > differen
> >
> > postgres=# set max_parallel_degree to 4;
> > SET
> > Time: 0.717
On 11 November 2015 at 17:59, Pavel Stehule wrote:
> Hi
>
> I have a first query
>
> I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are
> differen
>
> postgres=# set max_parallel_degree to 4;
> SET
> Time: 0.717 ms
> postgres=# EXPLAIN ANALYZE select count(*) from xxx where a
Hi
I have a first query
I looked on EXPLAIN ANALYZE output and the numbers of filtered rows are
differen
postgres=# set max_parallel_degree to 4;
SET
Time: 0.717 ms
postgres=# EXPLAIN ANALYZE select count(*) from xxx where a % 10 = 0;
┌
On Sun, Nov 8, 2015 at 11:13 PM, Etsuro Fujita
wrote:
> To test this change, I think we should update the postgres_fdw patch so as
> to add the RecheckForeignScan.
>
> Having said that, as I said previously, I don't see much value in adding the
> callback routine, to be honest. I know KaiGai-san
Peter Eisentraut writes:
> On 11/2/15 4:07 PM, Tom Lane wrote:
>> I wonder how much we need that script at all though. If, say, configure
>> doesn't find bison, what's so wrong with just defining BISON=bison and
>> letting the usual shell "bison: command not found" error leak through?
> I agree.
On 11/2/15 4:07 PM, Tom Lane wrote:
> I wonder how much we need that script at all though. If, say, configure
> doesn't find bison, what's so wrong with just defining BISON=bison and
> letting the usual shell "bison: command not found" error leak through?
I agree. Something like the attached pat
According to
https://bugzilla.redhat.com/show_bug.cgi?id=1280404
we're failing to build against Python 3.5 because the python guys
have randomly changed some error message texts, again.
In the short run the answer must be to add some more variant
expected-files, but I wonder if we should be looki
On 11/10/15 12:03 PM, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
>> Translation updates
>>
>> Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
>> Source-Git-Hash: cd263526676705b4a8a3a708c9842461c4a2bcc3
>
> Hi Peter,
>
> Would you please document this process?
It's d
I wrote:
> When I checked the behavior of 5d1ff6bd559ea8df, I must have only
> tried it for unshared catalogs. Those are set up by
> RelationCacheInitializePhase3, which is post-authentication, so the
> message comes out and causes regression test failures as expected.
> This is kind of annoying
2015-11-11 12:25 GMT+01:00 YUriy Zhuravlev :
> On Friday 06 November 2015 12:55:44 you wrote:
> > Omitted bounds are common in other languages and would be handy. I
> > don't think they'd cause any issues with multi-dimensional arrays or
> > variable start-pos arrays.
>
> And yet, what about my pa
В письме от 28 октября 2015 16:57:36 пользователь Michael Paquier написал:
> On Sat, Oct 17, 2015 at 1:48 AM, Michael Paquier wrote:
> > On Sat, Oct 17, 2015 at 5:15 AM, Nikolay Shaplov wrote:
> >> Or it's ready to commit, and just not marked this way?
> >
> > No, I don't think we have reached thi
2015-11-11 16:18 GMT+01:00 Thom Brown :
> On 11 November 2015 at 14:53, Robert Haas wrote:
> > On Mon, Nov 9, 2015 at 11:15 AM, Amit Kapila
> wrote:
> >> Okay, I have updated the patch to make seq scan node parallel aware.
> >> To make that happen we need to have parallel_aware flag both in Plan
On 11 November 2015 at 14:53, Robert Haas wrote:
> On Mon, Nov 9, 2015 at 11:15 AM, Amit Kapila wrote:
>> Okay, I have updated the patch to make seq scan node parallel aware.
>> To make that happen we need to have parallel_aware flag both in Plan
>> as well as Path, so that we can pass that infor
On Wed, Nov 11, 2015 at 11:53 PM, Robert Haas wrote:
> For those following along at home, here's a demo:
>
> rhaas=# \timing
> Timing is on.
> rhaas=# select * from pgbench_accounts where filler like '%a%';
> aid | bid | abalance | filler
> -+-+--+
> (0 rows)
>
> Time: 743
On Mon, Nov 9, 2015 at 11:15 AM, Amit Kapila wrote:
> Okay, I have updated the patch to make seq scan node parallel aware.
> To make that happen we need to have parallel_aware flag both in Plan
> as well as Path, so that we can pass that information from Path to Plan.
> I think the right place to
On Mon, Nov 9, 2015 at 8:23 PM, Pavel Stehule
wrote:
> 2015-11-09 17:55 GMT+01:00 Alexander Korotkov :
>
>> On Mon, Nov 9, 2015 at 4:53 PM, Pavel Stehule
>> wrote:
>>
>>> 2015-11-09 14:44 GMT+01:00 YUriy Zhuravlev :
>>>
On Monday 09 November 2015 13:50:20 Pavel Stehule wrote:
> New sym
On Tue, Nov 10, 2015 at 2:18 AM, Pavel Stehule wrote:
> Hi
>
> 2015-11-05 22:23 GMT+01:00 Robert Haas :
>>
>> On Thu, Nov 5, 2015 at 3:53 PM, Catalin Iacob
>> wrote:
>> > On Thu, Nov 5, 2015 at 5:27 PM, Robert Haas
>> > wrote:
>> >>> I wrote some text. But needs some work of native speaker.
>> >
On 11/11/15 5:03 AM, Marko Tiikkaja wrote:
> Dealing with "numeric"s right now in cases where it's really important
> that the scale is correct is quite painful. For example, if I want to
> accept a EUR amount as an input, I often want to reject values such as
> '21.413', but I'd be fine with e.g.
On 11 November 2015 at 16:02, Torsten Zühlsdorff <
mailingli...@toco-domains.de> wrote:
> From my experience most databases are just tpo small. Their operations
> finish before there can be a deadlock. Same for race conditions - most
> developer don't know about them, because they never stumbled
On 11/09/2015 10:32 PM, Ildus Kurbangaliev wrote:
On Nov 9, 2015, at 7:56 PM, Alvaro Herrera wrote:
Ildus Kurbangaliev wrote:
Thanks for the review. I've attached a new version of SLRU patch. I've
removed add_postfix and fixed EXEC_BACKEND case.
Thanks.
Please do not use "committs" in co
On 11 November 2015 at 06:04, Michael Paquier wrote:
>>> I also modified some of the CHECKFLOATVAL() checks which didn't look
>>> right to me, unless there's some odd platform-specific behaviour that
>>> I'm not aware of, functions like sin and asin should never return
>>> infinity.
>
> - CH
On Friday 06 November 2015 12:55:44 you wrote:
> Omitted bounds are common in other languages and would be handy. I
> don't think they'd cause any issues with multi-dimensional arrays or
> variable start-pos arrays.
And yet, what about my patch?
Discussions about ~ and{:} it seems optional.
Thank
On Wed, Nov 11, 2015 at 3:23 AM, Simon Riggs wrote:
> This causes every writer to wait.
>
> What we want is to isolate the wait only to people performing a write-read
> sequence, so I think it should be readers that wait. Let's have that debate
> up front before we start reviewing the patch.
One
On Wed, Nov 11, 2015 at 11:22 AM, Thomas Munro
wrote:
> On Wed, Nov 11, 2015 at 9:42 PM, Heikki Linnakangas wrote:
>> On 11/11/2015 10:23 AM, Simon Riggs wrote:
>>> Thanks for working on this issue.
>>
>> +1.
+1. I have seen a lot of interest for something along these lines.
>> I'm thinking the
Hi,
Dealing with "numeric"s right now in cases where it's really important
that the scale is correct is quite painful. For example, if I want to
accept a EUR amount as an input, I often want to reject values such as
'21.413', but I'd be fine with e.g. '21.41'. My suggestion is to
add tw
On Wed, Nov 11, 2015 at 9:42 PM, Heikki Linnakangas wrote:
> On 11/11/2015 10:23 AM, Simon Riggs wrote:
>
>> On 11 November 2015 at 05:37, Thomas Munro > >
>> wrote:
>>
>> Many sites use hot standby servers to spread read-heavy workloads over
>> more
>>
>>> hardware, or at least would like to. T
> I'm thinking the client should get some kind of a token back from the
commit, and it could use the token on the standby, to wait for that commit
to be applied. The token could be just the XID, or the LSN of the commit
record. Or the application could generate the token and pass it to the
server i
On 11/11/2015 10:23 AM, Simon Riggs wrote:
On 11 November 2015 at 05:37, Thomas Munro
wrote:
Many sites use hot standby servers to spread read-heavy workloads over more
hardware, or at least would like to. This works well today if your
application can tolerate some time lag on standbys. The
On 10.11.2015 07:23, Craig Ringer wrote:
On 10 November 2015 at 01:38, Jeff Janes wrote:
this would be handy in conjunction with LIMIT
(which also doesn't exist for UPDATE right now).
... and, in turn, UPDATE ... ORDER BY ..., since LIMIT without ORDER
BY is usually not a great choice.
I'
On 11 November 2015 at 05:37, Thomas Munro
wrote:
Many sites use hot standby servers to spread read-heavy workloads over more
> hardware, or at least would like to. This works well today if your
> application can tolerate some time lag on standbys. The problem is that
> there is no guarantee of
74 matches
Mail list logo
