On Fri, Jun 24, 2016 at 2:38 PM, Mithun Cy wrote:
> On Thu, Jun 16, 2016 at 12:58 PM, Amit Kapila
> wrote:
>
> I have a question regarding code changes in _hash_first.
>
> +/*
> + * Conditionally get the lock on primary bucket page for search
> while
> +* holding lock on m
On 24 June 2016 at 21:34, Tom Lane wrote:
>
> TBH, this looks more like a compiler bug than anything else.
I tend to agree. Especially since valgrind has no complaints on x64 linux,
and neither does DrMemory for 32-bit builds with the same toolchain on the
same Windows and same SDK.
I don't s
For test I wrote script in Python, which calls a test function via psycopg2:
#!/usr/bin/env python2
import psycopg2
conn = psycopg2.connect('xxx')
cursor = conn.cursor()
cursor.execute('set application_name to \'TEST\'')
for i in range(1, 100):
cursor.execute('select test()')
conn
On Fri, Jun 24, 2016 at 4:29 PM, Andres Freund wrote:
> As a motivation, here's a somewhat juicy example of the benefits that
> can be gained (disabled parallelism, results vary too much):
> SELECT l_linestatus, SUM(l_quantity) FROM lineitem GROUP BY 1 ORDER BY 2 DESC
> LIMIT 10 ;
> non-optimized
On Fri, Jun 24, 2016 at 11:35 AM, Álvaro Hernández Tortosa
wrote:
>
>
> On 24/06/16 14:23, Flavius Anton wrote:
>>
>> On Thu, Jun 23, 2016 at 2:54 PM, Flavius Anton
>> wrote:
>>>
>>> On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark wrote:
On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton
Hi,
On 2016-06-24 16:29:53 -0700, Andres Freund wrote:
> Comments so far? Different suggestions on how to get improvements
> around this merged?
Oh, and if somebody is interested on collaborating on some of
these... This is far too big for me to tackle alone.
Andres
--
Sent via pgsql-hacker
Hi,
at pgcon, in [1], and various other threads and conferences we talked
about our executor performance needing improvements to perform well in
!OLTP workloads, and how we can get there.
I've played with various techniques, on and off over the last few
weeks. Including trying to make slot_deform
On Fri, Jun 24, 2016 at 6:41 PM, Andrey Zhidenkov <
andrey.zhiden...@gmail.com> wrote:
> For example, when I call this procedure
> many times,
Call how? Specifically, how are you handling transactions in the calling
client? And what/how are you measuring memory consumption?
David J.
After some further testing, I noticed a case that wasn't handled in
heap_update, which I also fixed. I reworded some comments here and
there, and pushed to all branches.
Further testing and analysis is welcome.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development,
On 06/24/2016 02:16 PM, Tom Lane wrote:
Robert Haas writes:
On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
wrote:
To me, 2016-02-30 is an invalid date that should generate an error.
I don't particularly disagree with that, but on the other hand, as
mentioned earlier, to_timestamp() is he
I have postgresql 9.4.8 on my server and I've noticed always growing
memory when I use plpython. I've made some tests and find a few
situations, when memory leaks. For example, when I call this procedure
many times, I can see an always growing memory:
create or replace
function test() returns bigi
On 25/06/16 08:33, Robert Haas wrote:
On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
wrote:
My observation has been that the PostgreSQL development group aims for
correctness and the elimination of surprising results. This was part of the
reason to eliminate a number of automatic casts to dat
On Fri, Jun 24, 2016 at 2:18 PM, Tom Lane wrote:
> Uh, why? It's not a large amount of code and it seems like removing
> it puts a fair-size hole in the symmetry of tuplesort's capabilities.
It's not a small amount of code either.
Removing the code clarifies the division of labor between COPYTU
Peter Geoghegan writes:
> On Thu, Jun 23, 2016 at 7:59 PM, Tom Lane wrote:
>> I think this may be premature in view of bug #14210. Even if we
>> don't reinstate use of this function to fix that, I'm not really
>> convinced we want to get rid of it; it seems likely to me that
>> we might want it
Robert Haas writes:
> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
> wrote:
>> To me, 2016-02-30 is an invalid date that should generate an error.
> I don't particularly disagree with that, but on the other hand, as
> mentioned earlier, to_timestamp() is here for Oracle compatibility,
> and
On Thu, Jun 23, 2016 at 7:59 PM, Tom Lane wrote:
> I think this may be premature in view of bug #14210. Even if we
> don't reinstate use of this function to fix that, I'm not really
> convinced we want to get rid of it; it seems likely to me that
> we might want it again.
You pushed a fix for bu
On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford
wrote:
> My observation has been that the PostgreSQL development group aims for
> correctness and the elimination of surprising results. This was part of the
> reason to eliminate a number of automatic casts to dates in earlier
> versions.
>
> To me
On Wed, Jun 22, 2016 at 5:16 AM, Ashutosh Bapat
wrote:
>> However, if we support deparsing subqueries, the remote query in the above
>> example could be rewritten into something like this:
>>
>> SELECT ss.c2 FROM t1 LEFT JOIN (SELECT t2.a, ROW(a, b) FROM t2) ss(c1, c2)
>> ON (t1.a = ss.c1);
>>
>>
On Wed, Jun 22, 2016 at 4:11 AM, Amit Langote
wrote:
>> In an outer join we have to differentiate between a row being null (because
>> there was no joining row on nullable side) and a non-null row with all
>> column values being null. If we cast the whole-row expression to a text
>> e.g. r.*::text
On Thu, Jun 23, 2016 at 11:00 PM, Alvaro Herrera
wrote:
> Well, it's not specifically related to domains -- it's related to the
> fact that pg_catalog objects mask the domain you created in the public
> schema, because pg_catalog is by default in front of all other schemas
> unless you explicitely
On Mon, Jun 20, 2016 at 4:47 AM, Etsuro Fujita
wrote:
> Here is a small patch to remove an unnecessary return from
> deparseFromExprForRel in contrib/postgres_fdw/deparse.c.
Seems like a good cleanup. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On 24/06/16 14:23, Flavius Anton wrote:
On Thu, Jun 23, 2016 at 2:54 PM, Flavius Anton wrote:
On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark wrote:
On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton wrote:
I'd love to talk more about this.
I thought quite a bit about this a few years ago but ne
On Thu, Jun 23, 2016 at 2:54 PM, Flavius Anton wrote:
> On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark wrote:
>> On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton wrote:
>>>
>>> I'd love to talk more about this.
>>
>> I thought quite a bit about this a few years ago but never really
>> picked up it to
On Tue, Jun 21, 2016 at 4:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jun 18, 2016 at 4:49 PM, Tom Lane wrote:
>>> With that thought in mind, I propose that the behavior of
>>> force_parallel_mode = regress is ill-designed so far as EXPLAIN is
>>> concerned. What it ought to do is s
Joshua D. Drake wrote:
> Yes but what makes it weird is this:
>
> postgres=# create domain text char(3);
> CREATE DOMAIN
>
> -- cool, no problem
>
> postgres=# create domain text char(2);
> ERROR: type "text" already exists
>
> -- as expected
>
> postgres=# \dD
> List of domains
On Fri, Jun 24, 2016 at 1:08 PM, Joshua D. Drake
wrote:
> On 06/23/2016 08:00 PM, Alvaro Herrera wrote:
>
>> Joshua D. Drake wrote:
>>
>>> Hey,
>>>
>>> So this came across my twitter feed:
>>>
>>> https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png
>>>
>>> I have verified the oddness with a newer ver
On 06/24/2016 09:26 AM, Steve Crawford wrote:
My observation has been that the PostgreSQL development group aims for
correctness and the elimination of surprising results. This was part of
the reason to eliminate a number of automatic casts to dates in earlier
versions.
To me, 2016-02-30 is an i
On 06/23/2016 08:00 PM, Alvaro Herrera wrote:
Joshua D. Drake wrote:
Hey,
So this came across my twitter feed:
https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png
I have verified the oddness with a newer version:
Well, it's not specifically related to domains -- it's related to the
fact that pg
My observation has been that the PostgreSQL development group aims for
correctness and the elimination of surprising results. This was part of the
reason to eliminate a number of automatic casts to dates in earlier
versions.
To me, 2016-02-30 is an invalid date that should generate an error.
Autom
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 20.06.2016 17:09, Albe Laurenz wrote:
Tom Lane wrote:
I don't necessarily have an opinion yet. I would like to see more than
just an unsupported assertion about what Oracle's behavior is. Also,
how
On 23.06.2016 20:40, Tom Lane wrote:
Robert Haas writes:
On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston
wrote:
My understanding is that is not going to change for 9.6.
That's exactly what is under discussion here.
I would definitely agree with David on that point. Making to_timestamp
> On Fri, Jun 24, 2016 at 1:28 PM, Craig Ringer
wrote:
> > I'd like more details from those whose installs are crashing. What exact
> > vcvars env did you run under, with which exact cl.exe version?
This is a Windows server 2012 R2 Standard.
Devenv: Microsoft Visual Studio 2013 Community Version
Hi Amit,
I tried creating 2-level partitioned table and tried to create simple table
using CTAS from the partitioned table. It gives a cache lookup error.
Here's the test
CREATE TABLE pt1_l (a int, b varchar, c int) PARTITION BY RANGE(a);
CREATE TABLE pt1_l_p1 PARTITION OF pt1_l FOR VALUES START (1
Craig Ringer writes:
> I have absolutely no idea why it's trying to access memory at what looks
> like (uint64)(-1) though. Nothing in the auto vars list:
> + &restrictlist 0x0043f7b0 {0x09e32600 {type=T_List (656)
> length=1 head=0x09e325e0 {data={ptr_value=...} ...} .
Hey,
So this came across my twitter feed:
https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png
I have verified the oddness with a newer version:
psql -U postgres
psql (9.5.3)
Type "help" for help.
postgres=# create domain text char(3);
CREATE DOMAIN
postgres=# create domain text char(2);
ERROR: t
On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer
wrote:
>> I was helping Haroon with this last night. I don't have access to the
>> original thread and he's not around so I don't know how much he said.
I'll
>> repeat our findings here.
Craig, I am around now looking into this. I'll update the list
Seems there's a small error in the upgrade script for citext for 1.1
to 1.2 which will cause min(citext) not to be parallel enabled.
max(citext)'s combinefunc is first set incorrectly, but then updated
to the correct value. I assume it was meant to set the combine
function for min(citext) instead.
I have been running bisect, it breaks at this commit:
*commit 100340e2dcd05d6505082a8fe343fb2ef2fa5b2a*
*Author: Tom Lane >*
*Date: Sat Jun 18 15:22:34 2016 -0400*
*Restore foreign-key-aware estimation of join relation sizes.*
*This patch provides a new implementation of the logic added
On 2016/06/24 17:38, Ashutosh Bapat wrote:
> On Fri, Jun 24, 2016 at 1:59 PM, Amit Langote wrote:
>> I'm now starting to wonder if it would be outright wrong to just use the
>> alias names of corresponding foreign tables directly for whole-row
>> references? So, instead of these in target lists of
On Thu, Jun 16, 2016 at 12:58 PM, Amit Kapila
wrote:
I have a question regarding code changes in *_hash_first*.
+/*
+ * Conditionally get the lock on primary bucket page for search
while
+* holding lock on meta page. If we have to wait, then release the
meta
+ *
On Wed, Jun 22, 2016 at 10:51 AM, Michael Paquier
wrote:
> This connection string is stored in shared memory in WalRcvData, and
> that's the case for a couple of releases now, so it has already a high
> footprint, though I agree that making that available at SQL level
> makes it even worse. Lookin
On Fri, Jun 24, 2016 at 1:59 PM, Amit Langote wrote:
> On 2016/06/24 15:44, Ashutosh Bapat wrote:
> >>
> >> I think the proposed idea of applying record::text explicit coercion to
> a
> >> whole-row reference in the IS NOT NULL condition in the CASE WHEN
> >> conversion would work as expected as
On 2016/06/24 15:44, Ashutosh Bapat wrote:
>>
>> I think the proposed idea of applying record::text explicit coercion to a
>> whole-row reference in the IS NOT NULL condition in the CASE WHEN
>> conversion would work as expected as you explained, but I'm concerned that
>> the cost wouldn't be negli
On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer
wrote:
>> I was helping Haroon with this last night. I don't have access to the
>> original thread and he's not around so I don't know how much he said.
I'll
>> repeat our findings here.
Craig, I am around now looking into this. I'll update the list
On 23 June 2016 at 21:59, Tom Lane wrote:
> Craig Ringer writes:
> > While writing some code that takes a connstring and adds some
> parameters, I
> > noticed that PQconninfoParse doesn't play well with PQconnectdbParams.
>
> > PQconnectdbParams takes a pair of equal-length arrays, one for keys
45 matches
Mail list logo
