Pavel Stehule writes:
> I like to discussion about syntax - a name "prepare_plans" and
> following list is just one (for me - practical) shot. I am sure so
> preparing all plans on function start is one functionality what we
> want - because it can to do early warnings when some in environments
>
Hello
2011/9/11 Tom Lane :
> Andy Colson writes:
>> [ Andy's dubious about adding plpgsql syntax to control this feature ]
>
> Yeah, that bothers me a lot too.
>
I like to discussion about syntax - a name "prepare_plans" and
following list is just one (for me - practical) shot. I am sure so
prep
On Sat, Sep 10, 2011 at 12:32 AM, Robert Haas wrote:
> On Thu, Sep 8, 2011 at 8:42 PM, Fujii Masao wrote:
>> Another idea to avoid spinlock contention is save the timestamp in
>> PgBackendStatus (which contains information for pg_stat_activity).
>> This enables us to write and read the timestamp
Hello
thank you very much for review
> Will always throw an error because at prepare time, the temp junk table wont
> exist. This patch implements new syntax to disable the check:
>
> create function test5() returns integer as $$
> #prepare_plans on_demand
> begin
> ...
>
> Was it Tom Lane that
Mark wrote:
> >There's some potentially useful information here:
> >http://www.postgresql.org/docs/9.0/interactive/textsearch-controls.html#TEXTSEARCH-RANKING
>
> Thanks for reply. I was reading the documentation of PostgreSQL, but there
> it is not written the name of the used methods. Everywhere
On Sun, Sep 11, 2011 at 01:51, Tom Lane wrote:
> Usually what people have meant when they ask for "function caching"
> is that multiple executions of a given stable function with the same
> argument values be folded to just one execution. In the general case
> that would require some sort of hash
> If I understand the limitations correctly, though, what this would do is
> cause functions to perform substantially differently if called with
> expressions as arguments instead of text constants, no? Seems like that
> would lead to some user confusion. Although, with stuff like now(), we
> al
On Sat, Sep 10, 2011 at 11:50 PM, Tom Lane wrote:
> Fujii Masao writes:
>> Currently createuser cannot create a role with REPLICATION privilege
>> because it doesn't have any option to do that. Which sometimes annoys
>> me when setting up replication. I'd like to propose to add new options
>> "-x
> The patch as given has a bunch of implementation issues, but I think
> it's close enough for crude performance testing, and your numbers do
> show a potential performance benefit. The question that I think is
> unresolved is whether the set of cases covered is wide enough to be
> useful in prac
On 18 August 2011 00:22, Josh Kupershmidt wrote:
> On Wed, Jul 20, 2011 at 11:38 PM, Josh Kupershmidt wrote:
>
>> Updated patch attached, along with a revised SQL script to make
>> testing easier. I can add this to the next CF.
>>
>> Note, there is a separate thread[1] with just the psql changes
Marti Raudsepp writes:
> On Sun, Sep 11, 2011 at 01:21, Tom Lane wrote:
>> I'm not that happy with overloading the ANALYZE keyword to mean this
>> But we could certainly use some other name --- I'm
>> inclined to suggest CHECK:
>>CHECK FUNCTION function_name(arglist);
> Just a thought: p
Marti Raudsepp writes:
> This is a proof of concept patch for recognizing stable function calls
> with constant arguments and only calling them once per execution. I'm
> posting it to the list to gather feedback whether this is a dead end
> or not.
Hmm. This is an interesting hack, but I'm not s
On Sun, Sep 11, 2011 at 01:21, Tom Lane wrote:
> I'm not that happy with overloading the ANALYZE keyword to mean this
> But we could certainly use some other name --- I'm
> inclined to suggest CHECK:
> CHECK FUNCTION function_name(arglist);
Just a thought: pg_check_function(oid)?
> People
Hi,
This is a proof of concept patch for recognizing stable function calls
with constant arguments and only calling them once per execution. I'm
posting it to the list to gather feedback whether this is a dead end
or not.
Last time when this was brought up on the list, Tom Lane commented
that doi
Andy Colson writes:
> [ Andy's dubious about adding plpgsql syntax to control this feature ]
Yeah, that bothers me a lot too.
> One option I'd thought about, was to extended ANALYZE to support functions.
That's actually quite a good idea, not least because the extra checking
happens only when y
I'm considering inventing a new mcxt.c primitive,
void MemoryContextSetParent(MemoryContext context, MemoryContext new_parent);
which would have the effect of delinking "context" from its current
parent context and attaching it as a child of the new specified parent.
(Any child contexts that it h
Purpose
Better test coverage of functions. On first call of a function, all sql
statements will be prepared, even those not directly called. Think:
create function test() returns void as $$
begin
if false then
select badcolumn from badtable;
end if;
end; $$ language plpgsql;
On lör, 2011-09-10 at 16:34 -0400, Tom Lane wrote:
> Of course, this means that just building a source tarball marked
> "alpha1" isn't real useful. If we're going to do alpha releases, we
> have to have buy-in from packagers (or at least from the Windows
> installer team) to do follow-on package w
On lör, 2011-09-10 at 23:29 +0300, Marti Raudsepp wrote:
> I, for one, do use alpha tarballs on my dev machines (when working on
> apps that use PostgreSQL). It gives me a concrete schedule to update
> them that's not too frequent and I can tell whether they need updating
> just by glancing at the
> Download numbers for the installers were bordering on noise compared
> to the GA builds last time I looked, double figures iirc. I don't
> know about the tarballs offhand and can't check ATM.
Can you check when you get a chance? I know that the DL numbers for the first
alphas were very low,
Peter Eisentraut writes:
> On tis, 2011-09-06 at 11:41 -0700, Josh Berkus wrote:
>> I think the alphas have been extremely valuable for testing.
> That's not my recollection. Obviously, it's hard to measure this one
> way or the other, but I don't recall there being a lot of test reports
> from
On Sat, Sep 10, 2011 at 22:52, Peter Eisentraut wrote:
> but I don't recall there being a lot of test reports
> from people who are not already contributors and could have used some
> other way to get the code.
I, for one, do use alpha tarballs on my dev machines (when working on
apps that use Po
On Saturday, September 10, 2011, Joshua Berkus wrote:
>
>> That's not my recollection. Obviously, it's hard to measure this one
>> way or the other, but I don't recall there being a lot of test
>> reports
>> from people who are not already contributors and could have used some
>> other way to get
On 09/10/2011 02:52 PM, Peter Eisentraut wrote:
On tis, 2011-09-06 at 11:41 -0700, Josh Berkus wrote:
I think the alphas have been extremely valuable for testing.
That's not my recollection. Obviously, it's hard to measure this one
way or the other, but I don't recall there being a lot of tes
> That's not my recollection. Obviously, it's hard to measure this one
> way or the other, but I don't recall there being a lot of test
> reports
> from people who are not already contributors and could have used some
> other way to get the code.
Do we have download stats for the alphas? Dave?
On tis, 2011-09-06 at 11:41 -0700, Josh Berkus wrote:
> I think the alphas have been extremely valuable for testing.
That's not my recollection. Obviously, it's hard to measure this one
way or the other, but I don't recall there being a lot of test reports
from people who are not already contribu
On tis, 2011-09-06 at 13:38 -0400, Robert Haas wrote:
> 2011/9/6 Bruce Momjian :
> > Devrim GÜNDÜZ wrote:
> >> Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest?
> >
> > We talked about it on core and no one seems interested in doing the
> > packaging. :-(
>
> Well I don't particu
On tis, 2011-09-06 at 17:25 +0300, Devrim GÜNDÜZ wrote:
> Oh, what if noone will be interested in packaging until the last
> commitfest?
Then nothing will happen.
> We need people to start testing features, without having to use git or
> such.
You can download daily snapshot tarballs.
--
Sent
On 09/10/2011 11:39 AM, Alexey Klyukin wrote:
Hi Andy,
On Sep 7, 2011, at 6:40 AM, Andy Colson wrote:
Hi Alexey, I was taking a quick look at this patch, and have a question for ya.
...
Where did the other warnings go? Its right though, line 570 is bad. It also
seems to have killed the
On Sat, 2011-09-10 at 13:21 -0400, Tom Lane wrote:
> > So, I chose to represent that as a separate
> > rngcollation and leave the typcollation 0. In other words, collation is
> > a concept internal to that range type and fixed at type definition time.
> > Range types are affected by their internal
Jeff Davis writes:
> My interpretation of collation for range types is different than that
> for arrays, so I'm presenting it here in case someone has an objection.
> An array type has the same typcollation as its element type. This makes
> sense, because comparison between arrays are affected by
Andy Colson writes:
> On 09/10/2011 11:43 AM, Thom Brown wrote:
>> On 10 September 2011 17:40, Andy Colson wrote:
>>> I'm playing with 9.2devel, and I can fill my logs with:
>>> WARNING: pgstat waiting for 5001623 usec (494 loops), file timestamp
>>> 368986878169601 target timestamp 368986897680
Hi!
On Thu, Sep 8, 2011 at 15:11, Marko Tiikkaja
wrote:
> Here's a patch for $SUBJECT based on the feedback here:
> http://archives.postgresql.org/message-id/9053.1295888...@sss.pgh.pa.us
I tried this patch and noticed something weird. This is probably not
intentional:
explain analyze select *
My interpretation of collation for range types is different than that
for arrays, so I'm presenting it here in case someone has an objection.
An array type has the same typcollation as its element type. This makes
sense, because comparison between arrays are affected by the COLLATE
clause.
Compar
On 09/10/2011 11:43 AM, Thom Brown wrote:
On 10 September 2011 17:40, Andy Colson wrote:
I'm playing with 9.2devel, and I can fill my logs with:
WARNING: pgstat waiting for 5001623 usec (494 loops), file timestamp
368986878169601 target timestamp 368986897680812 last errno 0
WARNING: pgstat
On 10 September 2011 17:40, Andy Colson wrote:
> I'm playing with 9.2devel, and I can fill my logs with:
>
> WARNING: pgstat waiting for 5001623 usec (494 loops), file timestamp
> 368986878169601 target timestamp 368986897680812 last errno 0
> WARNING: pgstat waiting for 5011780 usec (495 loops)
I'm playing with 9.2devel, and I can fill my logs with:
WARNING: pgstat waiting for 5001623 usec (494 loops), file timestamp
368986878169601 target timestamp 368986897680812 last errno 0
WARNING: pgstat waiting for 5011780 usec (495 loops), file timestamp
368986878169601 target timestamp 3689
Hi Andy,
On Sep 7, 2011, at 6:40 AM, Andy Colson wrote:
> Hi Alexey, I was taking a quick look at this patch, and have a question for
> ya.
>
...
> Where did the other warnings go? Its right though, line 570 is bad. It also
> seems to have killed the server. I have not gotten through the h
Fujii Masao writes:
> Currently createuser cannot create a role with REPLICATION privilege
> because it doesn't have any option to do that. Which sometimes annoys
> me when setting up replication. I'd like to propose to add new options
> "-x (--replication)" and "-X (--no-replication)" into create
On Sat, Sep 10, 2011 at 15:44, Dimitri Fontaine wrote:
> I believe this bug has already been fixed, but the fix is not in rc1.
Thanks Thom and Dimitri, I'll make sure to test my bug reports with
git master in the future. :)
Regards,
Marti
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
Marti Raudsepp writes:
> Creating an extension in a schema and then dropping that schema
> apparently doesn't clean up the extension's types:
I believe this bug has already been fixed, but the fix is not in rc1.
http://archives.postgresql.org/pgsql-bugs/2011-08/msg00120.php
http://git.postg
On 10 September 2011 12:46, Marti Raudsepp wrote:
> Hi!
>
> Creating an extension in a schema and then dropping that schema
> apparently doesn't clean up the extension's types:
> db=# CREATE SCHEMA foo;
> db=# CREATE EXTENSION cube WITH SCHEMA foo;
> db=# DROP SCHEMA foo CASCADE;
> NOTICE: drop c
Hi!
Creating an extension in a schema and then dropping that schema
apparently doesn't clean up the extension's types:
db=# CREATE SCHEMA foo;
db=# CREATE EXTENSION cube WITH SCHEMA foo;
db=# DROP SCHEMA foo CASCADE;
NOTICE: drop cascades to 6 other objects
DETAIL: drop cascades to operator foo.
On Friday, September 09, 2011 08:59:43 PM Florian Pflug wrote:
> On Sep8, 2011, at 15:09 , Aidan Van Dyk wrote:
> > Personally, I think both of these show examples of why PG should be
> > looking hard at either providing a simple robust local directory based
> > archive_command, or very seriously p
44 matches
Mail list logo
