On 07/10/2013 07:28 AM, Atri Sharma wrote:
I am not sure if the part you mentioned is inline with the case I am
talking about.
Can you please post an example of such a join removal? I mean a query
before and after the removal. Thanks,
//Tony
--
Sent via pgsql-hackers mailing list (pgsql-hac
Hello Tatsuo,
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
On Wed, Jul 10, 2013 at 8:29 AM, Ashutosh Bapat
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 actually planning the joins.
>
On Wed, Jul 10, 2013 at 12:58 AM, Mike Blackwell 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 complete. In add
> 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.
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 wrote:
> My main
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 k
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
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
Managem
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 h
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 summa
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 m
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 LIK
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
Magnus Hagander 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
http://2ndQuadrant.fr Postgr
Salut Dimitri,
On 07/09/2013 12:40 PM, Dimitri Fontaine wrote:
> Markus Wanner 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 template
On Fri, Jul 5, 2013 at 3:01 PM, Josh Berkus wrote:
> On 07/05/2013 12:26 PM, Tom Lane wrote:
>> ivan babrou 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 to mysql, redis and othe
Markus Wanner 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 from some ful
Magnus Hagander writes:
> On Tue, Jul 9, 2013 at 5:56 PM, Dimitri Fontaine
> 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 default view, which would match our b
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
On Tue, Jul 9, 2013 at 5:56 PM, Dimitri Fontaine wrote:
> Andres Freund 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
> cgi
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:30 PM, Andres Freund 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 curious
Peter Eisentraut 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. Requiring P
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
buildin
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:
http://www.postgresql
On 07/08/2013 10:49 PM, Daniel Farina wrote:
> On Mon, Jul 8, 2013 at 7:25 PM, Craig Ringer 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. Running them as "EBS
On 9 July 2013 17:59, Markus Wanner 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 check
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 wrote:
>
> Hello Robins,
>
>
> PFA an updated patch:
>> - Renamed ROLEs as per ne
On 9 July 2013 12:20, Markus Wanner 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 during norma
On 9 July 2013 11:05, Markus Wanner 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 seconds delay.
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
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 wa
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
Andres Freund 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 the latest patch on all
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 frequ
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 maili
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.
--
Fabien.
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 (pgsql-hack
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
> se
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
f
2013/7/9 Merlin Moncure
> On Fri, Jul 5, 2013 at 12:28 PM, 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 t
On Sun, Jul 7, 2013 at 4:27 PM, Sawada Masahiko wrote:
> On Sun, Jul 7, 2013 at 4:19 PM, Sawada Masahiko wrote:
>> On Mon, Jun 17, 2013 at 8:48 PM, Simon Riggs wrote:
>>> On 17 June 2013 09:03, Pavan Deolasee wrote:
>>>
I agree. We should probably find a better name for this. Any suggestio
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 i
On 07/08/2013 11:03 PM, Peter Geoghegan wrote:
On Mon, Jul 8, 2013 at 7:59 PM, Peter Eisentraut 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 final patch ough
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 Fri, Jul 5, 2013 at 12:28 PM, 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 revi
Peter Eisentraut 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 to get a snaps
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
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
wrote in
<20130708.165905.118860769.horiguchi.kyot...@lab.ntt.co.jp>
> I'll come again with the first implementation of it. And as for
>
Markus Wanner 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 (installed on
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
On 2013-07-09 08:00:52 +0900, Michael Paquier wrote:
> On Mon, Jul 8, 2013 at 6:16 PM, Heikki Linnakangas
> 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
this bottleneck is
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 Tue, Jul 9, 2013 at 3:33 AM, James Sewell wrote:
> 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 in the next commitf
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 alr
On Tue, Jul 9, 2013 at 12:24 AM, Jesper Krogh 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 3.500/hr
On Sat, Jul 6, 2013 at 9:20 AM, Kevin Grittner wrote:
> Hitoshi Harada 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 view mv as select * from
>
> 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
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:
59 matches
Mail list logo
