On Sun, Jul 7, 2013 at 12:06 PM, Peter Eisentraut pete...@gmx.net wrote:
On Thu, 2013-07-04 at 02:18 -0700, Hitoshi Harada wrote:
as someone suggested in the previous thread, it might be a variant of
CAST. CREATE CAST (hstore AS plpython2u) ? Or CREATE LANGUAGE TRANSFORM
might sound better.
Hi all,
I was reading about the plans to add functionality to the planner to
remove redundant inner joins where there is no member of the inner
relation present in the target list and the inner relation is only
used for the join clause. Also, we have a foreign key in the outer
relation to the
On Mon, Jul 8, 2013 at 11:20 PM, Atri Sharma atri.j...@gmail.com wrote:
Where are we with that functionality atm? Do we have plans to move forward?
PostgreSQL has had this capability for some time. See:
On 2013-07-08 23:31:15 -0700, Peter Geoghegan wrote:
On Mon, Jul 8, 2013 at 11:20 PM, Atri Sharma atri.j...@gmail.com wrote:
Where are we with that functionality atm? Do we have plans to move forward?
PostgreSQL has had this capability for some time. See:
On Tue, Jul 9, 2013 at 12:01 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Jul 8, 2013 at 11:20 PM, Atri Sharma atri.j...@gmail.com wrote:
Where are we with that functionality atm? Do we have plans to move forward?
PostgreSQL has had this capability for some time. See:
On Mon, Jul 8, 2013 at 11:33 PM, Andres Freund and...@2ndquadrant.com wrote:
That's for outer joins tho.
Oh, right - I spoke too soon. Looks like I missed the whole discussion
on inner join removal.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 5 July 2013 19:49, Josh Berkus j...@agliodbs.com wrote:
Robert, Simon, All,
On 04/01/2013 04:51 AM, Robert Haas wrote: On Thu, Mar 28, 2013 at
11:48 AM, Simon Riggs si...@2ndquadrant.com wrote:
a) recovery parameters are made into GUCs (for which we have a patch
from Fujii)
b) all
My main point here is researching how difficult it is to add
functionality in the planner to allow it to to detect and make
decisions on foreign keys present in the outer relation.
I think that if this is added, rest of the work would be much easier.
I amy be completely wrong,though.
On Thu, Jul 4, 2013 at 2:18 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
For now, that's it. I'm going to dig more later.
After looking into rest of the change,
- TYPTYPE_DOMAIN is not supported. Why did you specifically disallow it?
- ParseFuncOrColumn now prohibits to find function
On 07/08/2013 08:31 PM, ivan babrou wrote:
Seriously, I don't get why running 150 poolers is easier.
Did you consider running pgbouncer on the database servers?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
The really, really big ones are useful even for pushing limits, such
as cr1.8xlarge, with 32 CPUs and 244GiB memory. Current spot instance
price (the heavily discounted can die at any time one) is $0.343/hr.
Otherwise, it's 3.500/hr.
Just to keep in mind cpus are similar throttled:
One
On Sat, Jul 6, 2013 at 9:20 AM, Kevin Grittner kgri...@ymail.com wrote:
Hitoshi Harada umi.tan...@gmail.com wrote:
Oops!
Indeed. Thanks for the careful testing.
drop materialized view if exists mv;
drop table if exists foo;
create table foo(a, b) as values(1, 10);
create materialized
On Tue, Jul 9, 2013 at 12:24 AM, Jesper Krogh jes...@krogh.cc wrote:
The really, really big ones are useful even for pushing limits, such
as cr1.8xlarge, with 32 CPUs and 244GiB memory. Current spot instance
price (the heavily discounted can die at any time one) is $0.343/hr.
Otherwise, it's
Hello Josh,
Generally speaking, I agree with Robert's objection. The patch in
itself adds only one unnecessary keyword, which probably wouldn't be
noticeable, but the argument for it implies that we should be willing
to add a lot more equally-unnecessary keywords, which I'm not. gram.o
is
On Tue, Jul 9, 2013 at 3:33 AM, James Sewell james.sew...@lisasoft.comwrote:
Hey,
New patch attached. I've moved from using a boolean to an enum trivalue.
Let me know what you think.
Please add your patch at
https://commitfest.postgresql.org/action/commitfest_view?id=19 so it's not
missed
On 07/09/2013 09:15 AM, ivan babrou wrote:
Database server lost network — boom, 2 seconds delay. What's the point then?
Oh, I see. Good point. It could still improve connection time during
normal operation, though.
None the less, I now agree with you: we recommend a pooler, which may be
capable
On 2013-07-09 08:00:52 +0900, Michael Paquier wrote:
On Mon, Jul 8, 2013 at 6:16 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Ok, I've committed this patch now. Finally, phew!
+1. Great patch!
And one more: +1
There seem to be quite some lowhanging fruits to make stuff faster after
I think that it is not that simple: it is a good value to check that the
syntax error message conveys a useful information for the user, and that
changes to the parser rules do not alter good quality error messages.
It's good to check those things when a feature is implemented. However,
once
Markus Wanner mar...@bluegap.ch writes:
Then what happens at pg_restore time? the CREATE EXTENSION in the backup
script will suddenly install the other extension's that happen to have
the same name? I think erroring out is the only safe way here.
Extensions are commonly identified by name
Hello, I've brought visibilitymap extentions for pg_freespacemap
and pgstattuple.
At Mon, 08 Jul 2013 16:59:05 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote in
20130708.165905.118860769.horiguchi.kyot...@lab.ntt.co.jp
I'll come again with the first
On 7/8/13 4:37 AM, Dimitri Fontaine wrote:
I don't know of any actual legitimate uses of local_preload_libraries.
I recall that the plpgsql debugger was meant to use it, but doesn't
anymore. So it's hard to judge what to do about this, without any
actual use cases.
Well there's my
Peter Eisentraut pete...@gmx.net writes:
preprepare has an SQL function as entry point, so you don't need to
preload it.
Well the whole goal of that extension is to autoload itself entirely
server side at connection time. The function API had been made to cope
with 8.3 where it wasn't possible
On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou ibob...@gmail.com wrote:
Hi, guys! I made a quick patch to support floating number in
connect_timeout param for libpq. This will treat floating number as
seconds so this is backwards-compatible. I don't usually write in C,
so there may be mistakes.
Ian,
On 07/05/2013 07:28 PM, ivan babrou wrote:
- /*
- * Rounding could cause connection to fail; need at
least 2 secs
- */
You removed this above comment... please check why it's there. The
relevant revision seems to be:
###
On 07/08/2013 11:03 PM, Peter Geoghegan wrote:
On Mon, Jul 8, 2013 at 7:59 PM, Peter Eisentraut pete...@gmx.net wrote:
I don't think rewriting it in Perl is necessary or even desirable. I
don't see anything particularly unportable in that script as it is.
I was under the impression that the
On 2013-07-05 21:28:59 +0400, ivan babrou wrote:
Hi, guys! I made a quick patch to support floating number in
connect_timeout param for libpq. This will treat floating number as
seconds so this is backwards-compatible. I don't usually write in C,
so there may be mistakes. Could you review it
On Sun, Jul 7, 2013 at 4:27 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Sun, Jul 7, 2013 at 4:19 PM, Sawada Masahiko sawada.m...@gmail.com wrote:
On Mon, Jun 17, 2013 at 8:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 17 June 2013 09:03, Pavan Deolasee pavan.deola...@gmail.com
2013/7/9 Merlin Moncure mmonc...@gmail.com
On Fri, Jul 5, 2013 at 12:28 PM, ivan babrou ibob...@gmail.com wrote:
Hi, guys! I made a quick patch to support floating number in
connect_timeout param for libpq. This will treat floating number as
seconds so this is backwards-compatible. I don't
I note that git.postgresql.org's robot.txt refuses permission to crawl
the git repository:
http://git.postgresql.org/robots.txt
User-agent: *
Disallow: /
I'm curious what motivates this. It's certainly useful to be able to
search for commits. I frequently type git commit hashes into Google to
On 2013-07-09 16:24:42 +0100, Greg Stark wrote:
I note that git.postgresql.org's robot.txt refuses permission to crawl
the git repository:
http://git.postgresql.org/robots.txt
User-agent: *
Disallow: /
I'm curious what motivates this. It's certainly useful to be able to
search for
PFA an updated patch:
- Renamed ROLEs as per new feedback (although the previous naming was also
as per an earlier feedback)
- Merged tests into namespace
I do not see any difference with v4. I guess you sent the earlier version.
--
Fabien.
--
Sent via pgsql-hackers mailing list
Please find updated patch:
- 'make check' successful with recent changes
- Renamed ROLEs as per feedback
Sorry, I took the wrong thread.
I do not see any difference between both regress_sequence_v[45].patch.
I guess you sent the earlier version.
--
Fabien.
--
Sent via pgsql-hackers
PFA an updated patch:
- Renamed ROLEs as per new feedback (although the previous naming was also
as per an earlier feedback)
- Merged tests into namespace
I do not see any difference with v4. I guess you sent the earlier version.
Sorry, wrong thread, this apply to SEQUENCE tests.
--
On 07/09/2013 11:24 AM, Greg Stark wrote:
I note that git.postgresql.org's robot.txt refuses permission to crawl
the git repository:
http://git.postgresql.org/robots.txt
User-agent: *
Disallow: /
I'm curious what motivates this. It's certainly useful to be able to
search for commits. I
Andres Freund and...@2ndquadrant.com writes:
Gitweb is horribly slow. I don't think anybody with a bigger git repo
using gitweb can afford to let all the crawlers go through it.
What's blocking alternatives to be considered? I already did mention
cgit, which has the advantage to clearly show
Hello Robins,
PFA an updated patch:
- Renamed ROLEs as per new feedback (although the previous naming was also
as per an earlier feedback)
- Merged tests into namespace
I cannot apply the patch, it seems to be truncated:
sh git apply ../regress_schema_v5.patch
### warnings about trailing
On 07/09/2013 10:40 AM, Andrew Dunstan wrote:
On 07/08/2013 11:03 PM, Peter Geoghegan wrote:
On Mon, Jul 8, 2013 at 7:59 PM, Peter Eisentraut pete...@gmx.net
wrote:
I don't think rewriting it in Perl is necessary or even desirable. I
don't see anything particularly unportable in that script
On 9 July 2013 11:05, Markus Wanner mar...@bluegap.ch wrote:
On 07/08/2013 08:31 PM, ivan babrou wrote:
Seriously, I don't get why running 150 poolers is easier.
Did you consider running pgbouncer on the database servers?
Regards
Markus Wanner
Database server lost network — boom, 2
On 9 July 2013 12:20, Markus Wanner mar...@bluegap.ch wrote:
On 07/09/2013 09:15 AM, ivan babrou wrote:
Database server lost network — boom, 2 seconds delay. What's the point then?
Oh, I see. Good point. It could still improve connection time during
normal operation, though.
Connection time
Hi Fabien,
Appreciate you being able to check right away.
Seems something went wrong with these set of patches... Would check again
and resubmit them soon.
--
Robins Tharakan
On 9 July 2013 10:57, Fabien COELHO coe...@cri.ensmp.fr wrote:
Hello Robins,
PFA an updated patch:
- Renamed
On 9 July 2013 17:59, Markus Wanner mar...@bluegap.ch wrote:
Ian,
On 07/05/2013 07:28 PM, ivan babrou wrote:
- /*
- * Rounding could cause connection to fail; need at
least 2 secs
- */
You removed this above comment... please
On 07/08/2013 10:49 PM, Daniel Farina wrote:
On Mon, Jul 8, 2013 at 7:25 PM, Craig Ringer cr...@2ndquadrant.com wrote:
I did some work on that a while ago, and found that I was able to get
_astonishingly_ stable performance results out of EC2 EBS instances
using provisioned IOPS volumes.
On 7/9/13 10:40 AM, Andrew Dunstan wrote:
This is actually a pretty trivial task. Here is a simple perl version:
But that would make Perl a hard build requirement.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 07/09/2013 01:55 PM, Peter Eisentraut wrote:
On 7/9/13 10:40 AM, Andrew Dunstan wrote:
This is actually a pretty trivial task. Here is a simple perl version:
But that would make Perl a hard build requirement.
Well, it already is unless you're not building from git AND you're not
Peter Eisentraut pete...@gmx.net writes:
On 7/9/13 10:40 AM, Andrew Dunstan wrote:
This is actually a pretty trivial task. Here is a simple perl version:
But that would make Perl a hard build requirement.
My opinion is that this script should only run if you've changed some
catalog .h files.
On Tue, Jul 9, 2013 at 5:30 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-07-09 16:24:42 +0100, Greg Stark wrote:
I note that git.postgresql.org's robot.txt refuses permission to crawl
the git repository:
http://git.postgresql.org/robots.txt
User-agent: *
Disallow: /
I'm
Dimitri,
leaving the template vs link model aside for a moment, here are some
other issues I run into. All under the assumption that we want the link
model.
On 07/08/2013 11:49 AM, Dimitri Fontaine wrote:
Please find attached to this mail version 9 of the Extension Templates
patch with fixes
On Tue, Jul 9, 2013 at 5:56 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Andres Freund and...@2ndquadrant.com writes:
Gitweb is horribly slow. I don't think anybody with a bigger git repo
using gitweb can afford to let all the crawlers go through it.
What's blocking alternatives to be
The most recent patch (v3) applies and builds cleanly and passes make
check. Documentation on the new SQL syntax and catalog changes is included
with the patch and looks good to me.
The regression tests look pretty complete. In addition to the included
tests, dropping and altering the data type
Magnus Hagander mag...@hagander.net writes:
On Tue, Jul 9, 2013 at 5:56 PM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
What's blocking alternatives to be considered? I already did mention
cgit, which has the advantage to clearly show the latest patch on all
the active branches in its
Markus Wanner mar...@bluegap.ch writes:
First of all, I figured that creation of a template of a newer version
is prohibited in case an extension exists:
Ooops, that's a bug I need to fix.
I then came to think of the upgrade scripts... what do we link against
if an extension has been created
On Fri, Jul 5, 2013 at 3:01 PM, Josh Berkus j...@agliodbs.com wrote:
On 07/05/2013 12:26 PM, Tom Lane wrote:
ivan babrou ibob...@gmail.com writes:
If you can figure out that postgresql is overloaded then you may
decide what to do faster. In our app we have very strict limit for
connect time
Salut Dimitri,
On 07/09/2013 12:40 PM, Dimitri Fontaine wrote:
Markus Wanner mar...@bluegap.ch writes:
Or how do you think would pg_restore fail, if you followed the mental
model of the template?
# create template for extension foo version 'x' as '';
# create extension foo;
# alter
Magnus Hagander mag...@hagander.net writes:
Oh, and we need stable wheezy packages for them, or we'll be paying
even more in maintenance. AFAICT, there aren't any for cgit, but maybe
I'm searching for the wrong thing..
Seems to be a loser on that front too.
--
Dimitri Fontaine
On 7/8/13 4:20 AM, Dimitri Fontaine wrote:
Let me stress that the most important value in that behavior is to be
able to pg_restore using a newer version of the extension, the one that
works with the target major version. When upgrading from 9.2 to 9.3 if
you depend on keywords that now are
Hi,
I am a newbie to PostgreSQL and was wondering about the following
behaviour.
SELECT true WHERE 1 = '1'; -- Returns true
SELECT true WHERE 1 BETWEEN '0' and '2';-- Returns true
SELECT true WHERE 1 IS DISTINCT FROM '2';-- Returns true
SELECT true WHERE 1 LIKE
Prabakaran,
I am a newbie to PostgreSQL and was wondering about the following
behaviour.
pgsql-hackers is not the appropriate list for this kind of question. In
the future, please post to pgsql-novice, pgsql-sql, or pgsql-general
with this kind of question. Thanks.
Can you please help me
On 07/08/2013 11:43 PM, Simon Riggs wrote:
This needs to be broken down rather than just say I like Greg's
proposal, or I have written a patch. Writing the patch is not the/an
issue.
Greg's points were these (I have numbered them and named/characterised them)
Thanks for the nice summary!
I would like to start using a newer version of docbook-xsl for the
release builds. This is currently used for building the man pages. The
latest release is 1.78.1 and fixes a few formatting errors.
How do we do that?
We could just take the latest Debian package and stick it on borka. I
don't
The only environment I have available at the moment is a virtual box.
That's probably not going to be very helpful for performance testing.
__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
On Mon, 2013-07-01 at 20:16 -0300, Fabrízio de Royes Mello wrote:
Hi all,
When we run...
./configure --enable-converage
make coverage-html
...the output is generated into /coverage/ directory. The attached patch
add /converage/ to .gitignore.
I have committed this. It should be
Hi Fabien,
I have looked into this:
https://commitfest.postgresql.org/action/patch_view?id=1105
because it's marked as Ready for committer. However I noticed that
you worried about other pgbench patches such as
https://commitfest.postgresql.org/action/patch_view?id=1103 .
So I would like to
AFAIK,
There is code to remove the redundant relations (joins too are relations).
But I don't remember exactly where it is. Start looking at query_planner().
The removal of relations should happen before actually planning the joins.
On Tue, Jul 9, 2013 at 12:21 PM, Atri Sharma
On Wednesday, July 10, 2013 6:32 AM Mike Blackwell wrote:
The only environment I have available at the moment is a virtual box. That's
probably not going to be very helpful for performance testing.
It's okay. Anyway thanks for doing the basic test for patch.
With Regards,
Amit Kapila.
On Wed, Jul 10, 2013 at 12:58 AM, Mike Blackwell mike.blackw...@rrd.com wrote:
The most recent patch (v3) applies and builds cleanly and passes make check.
Documentation on the new SQL syntax and catalog changes is included with the
patch and looks good to me.
The regression tests look pretty
On Wed, Jul 10, 2013 at 8:29 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
AFAIK,
There is code to remove the redundant relations (joins too are relations).
But I don't remember exactly where it is. Start looking at query_planner().
The removal of relations should happen before
66 matches
Mail list logo
