On Wednesday, April 11, 2012, Robert Haas wrote:
> On Tue, Apr 10, 2012 at 10:05 PM, Peter Geoghegan
> >
> wrote:
> > On 11 April 2012 02:14, Robert Haas >
> wrote:
> >> My perception of what's going on here is dramatically different from
> >> yours. I don't think there was any overflow of submi
>
>I think Multicorn is a good example, which invokes Python from FDW
>routines though it is not using PL/Python.
>
>http://multicorn.org/
>
>
Hi Hitoshi,
Thanks for the link.
You mean,I should try to build something like Multicorn for Java?
Atri
--
Sent via pgsql-hackers mailing list (pgsql
On Tue, Apr 10, 2012 at 8:41 PM, Atri Sharma wrote:
> Hi All,
>
> I think we are back on the initial approach I proposed(hooking directly into
> the JVM and executing Java code that calls JDBC).I think the best way to do
> this is create a JVM that executes the Java code and give the control of th
>> I agree that JNI isn't required -- we're going to
>> have to study the pl/java system a bit to determine the best way to
>> hook in. This could end up getting us into the 'biting of more than
>> can chew' territory admittedly, but Atri is enthusiastic and wants to
>> give it a go.
>
>Well. may
Robert Haas writes:
> On Tue, Apr 10, 2012 at 9:37 PM, Tom Lane wrote:
>> Well, the other thing we could do is tweak the rules for when to print a
>> complaint. I notice that in check_temp_tablespaces we use the rule
>>
>>source == PGC_S_SESSION (ie, SET) -> error
>>source == PG
On Tue, Apr 10, 2012 at 9:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 10, 2012 at 7:14 PM, Tom Lane wrote:
>>> Anyway, if you're happy with 9.1 being an outlier on this behavior,
>>> I won't press the point.
>
>> I'm not, particularly.
>
> Well, the other thing we could do is twe
On Tue, Apr 10, 2012 at 10:05 PM, Peter Geoghegan wrote:
> On 11 April 2012 02:14, Robert Haas wrote:
>> My perception of what's going on here is dramatically different from
>> yours. I don't think there was any overflow of submissions for 9.2.
>
> That is just not true. See the attached graph (
On Fri, Mar 30, 2012 at 08:16:59PM +0300, Peter Eisentraut wrote:
> On fre, 2012-03-23 at 07:52 -0700, David Fetter wrote:
> > On Thu, Mar 22, 2012 at 06:05:30PM -0400, Andrew Dunstan wrote:
> > > On 03/22/2012 05:49 PM, Bruce Momjian wrote:
> > > >Robert Haas and I are disappointed by this change.
On Tue, Apr 10, 2012 at 9:32 PM, Andres Freund wrote:
> They might have been half-baked. But several of those didn't get design-level
> review for several weeks which makes it rather hard to fully bake them in
> time...
Yeah, I noticed. People other than committers can do design reviews,
of cour
Peter Geoghegan writes:
> That is just not true. See the attached graph (couldn't produce one
> with better resolution at short notice) - I've just eyeballed the
> graph, but it looks like an upward trend to me.
[ scratches head... ] That's supposed to be total lines of code in our
source tree?
On Tue, Apr 10, 2012 at 09:19:05PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Apr 10, 2012 at 7:57 PM, Tom Lane wrote:
> >> If we expect this function to mainly be applied to pg_class.reltablespace,
> >> then it seems like it ought to understand that zero means "the database
> >> de
On 11 April 2012 02:14, Robert Haas wrote:
> My perception of what's going on here is dramatically different from
> yours. I don't think there was any overflow of submissions for 9.2.
That is just not true. See the attached graph (couldn't produce one
with better resolution at short notice) - I'
Andres Freund writes:
> On Wednesday, April 11, 2012 03:14:41 AM Robert Haas wrote:
>> My perception of what's going on here is dramatically different from
>> yours. I don't think there was any overflow of submissions for 9.2.
>> For the most part I would describe it as a slow and boring release
On Wednesday, April 11, 2012 03:14:41 AM Robert Haas wrote:
> > I'm somewhat oddly pleased at how the overflow of incoming submissions
> > for 9.2 has raised questions around not having enough active committers.
> > I hope decisions about adding more recognizes that distributing that
> > power rea
Robert Haas writes:
> On Tue, Apr 10, 2012 at 7:14 PM, Tom Lane wrote:
>> Anyway, if you're happy with 9.1 being an outlier on this behavior,
>> I won't press the point.
> I'm not, particularly.
Well, the other thing we could do is tweak the rules for when to print a
complaint. I notice that i
On Tue, Apr 10, 2012 at 10:28 AM, Robert Haas wrote:
>
> It's feasible to think that we might be able to streamline the process
> of booting patches that are not close to committable at the start of a
> CommitFest, and especially at the start of the final CommitFest.
I'd usually consider "booting
On 03/06/2012 04:35 PM, Jeff Janes wrote:
On my testing, this dirty-before-evict is because the bgwriter is
riding too far ahead of the clock sweep, because of
scan_whole_pool_milliseconds. Because it is far ahead, that leaves a
lot of run between the two pointers for re-dirtying cache hits to
l
Robert Haas writes:
> On Tue, Apr 10, 2012 at 7:57 PM, Tom Lane wrote:
>> If we expect this function to mainly be applied to pg_class.reltablespace,
>> then it seems like it ought to understand that zero means "the database
>> default" and substitute the database's default tablespace. That might
On Tue, Apr 10, 2012 at 7:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane wrote:
>>> I am not sure whether we should consider back-patching this into 9.1,
>>> although that would be necessary if we wanted to fix Robert's original
>>> complaint against 9.
On Tue, Apr 10, 2012 at 8:43 PM, Greg Smith wrote:
> To use a personal example I don't think is unique, I would set aside more
> time to hack on the documentation if I didn't have to bug one of the
> existing committers each time I wanted to work on something there. It really
> feels like I'm wast
On Tue, Apr 10, 2012 at 7:57 PM, Tom Lane wrote:
> If we expect this function to mainly be applied to pg_class.reltablespace,
> then it seems like it ought to understand that zero means "the database
> default" and substitute the database's default tablespace. That might
> or might not be the sam
On 11 April 2012 01:16, Tom Lane wrote:
> Peter Geoghegan writes:
>> On 11 April 2012 00:35, Robert Haas wrote:
>>> If people need something like that, couldn't they create it by hashing
>>> the normalized query text with an arbitrary algorithm?
>
>> That supposes that the normalised query text
On Tue, Apr 10, 2012 at 10:38 AM, Peter Eisentraut wrote:
> On tis, 2012-04-03 at 22:34 -0700, Josh Kupershmidt wrote:
>> I noticed psql's tab-completion for 'WITH' is a bit overeager. If you
>> try to tab-complete commands like:
>> ALTER ROLE jsmith WITH [TAB]
>> COPY tbl FROM 'filename' WITH
On Tue, Apr 10, 2012 at 08:22:15PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Apr 10, 2012 at 07:57:30PM -0400, Tom Lane wrote:
> >> If we expect this function to mainly be applied to pg_class.reltablespace,
> >> then it seems like it ought to understand that zero means "the databa
On 04/10/2012 01:28 PM, Robert Haas wrote:
The fact is that we have no shortage of committers - there are 19
people who have access to push code into our master git repository. A
handful of those people have basically completely left the project and
their commit rights should probably be revoked
I wrote:
> AFAICS your patch does not avoid the fact that the function will throw
> error on a zero input.
Oh, no, scratch that --- I was thinking that you were applying the
function directly to pg_class.reltablespace, but you're applying it to
pg_tablespace.oid, so the issue should not arise.
Bruce Momjian writes:
> On Tue, Apr 10, 2012 at 07:57:30PM -0400, Tom Lane wrote:
>> If we expect this function to mainly be applied to pg_class.reltablespace,
>> then it seems like it ought to understand that zero means "the database
>> default" and substitute the database's default tablespace.
Peter Geoghegan writes:
> On 11 April 2012 00:35, Robert Haas wrote:
>> If people need something like that, couldn't they create it by hashing
>> the normalized query text with an arbitrary algorithm?
> That supposes that the normalised query text is perfectly stable. It
> may well not be, parti
On Tue, Apr 10, 2012 at 11:53:23AM -0500, Kevin Grittner wrote:
> Tom Lane wrote:
> > "Kevin Grittner" writes:
> >> One other sort of mechanical test which I think can and should be
> >> applied to patches submitted to the last CF is that if *at the
> >> start of the CF* the patch doesn't apply,
On Tue, Apr 10, 2012 at 07:57:30PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Apr 10, 2012 at 07:09:33PM -0400, Tom Lane wrote:
> >> Hm. I have no objection to special-casing zero here, but what behavior
> >> do you want? Should it return an empty string as we do for
> >> DEFAULT
On Thu, Mar 22, 2012 at 02:55:32PM +0200, Ants Aasma wrote:
> Hi,
>
> while working on a support case I stumbled upon a bug in pg_upgrade.
> Upgrade fails with "No such file or directory" when a database is
> moved to a non-default tablespace and contains a table that is moved
> to pg_default. The
On 11 April 2012 00:35, Robert Haas wrote:
> If people need something like that, couldn't they create it by hashing
> the normalized query text with an arbitrary algorithm?
That supposes that the normalised query text is perfectly stable. It
may well not be, particularly for things like ad-hoc qu
Bruce Momjian writes:
> On Tue, Apr 10, 2012 at 07:09:33PM -0400, Tom Lane wrote:
>> Hm. I have no objection to special-casing zero here, but what behavior
>> do you want? Should it return an empty string as we do for
>> DEFAULTTABLESPACE_OID, or throw a different error?
> I have no idea. The
Peter Geoghegan writes:
> On 10 April 2012 23:07, Greg Smith wrote:
>> On 04/10/2012 12:27 PM, Tom Lane wrote:
>> I am doing more sophisticated things with it, so I'll celebrate this as my
>> opportunity to say I did something you didn't see coming for 2012.
> This is why I requested that we exp
On Tue, Apr 10, 2012 at 6:32 PM, Peter Geoghegan wrote:
> On 10 April 2012 23:07, Greg Smith wrote:
>> On 04/10/2012 12:27 PM, Tom Lane wrote:
>> I am doing more sophisticated things with it, so I'll celebrate this as my
>> opportunity to say I did something you didn't see coming for 2012.
>
> Th
On Tue, Apr 10, 2012 at 07:09:33PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Apr 10, 2012 at 06:16:31PM -0400, Robert Haas wrote:
> >> On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane wrote:
> >>> The way the function is coded, it has no need to look into pg_tablespace
> >>> as such, wh
Robert Haas writes:
> On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane wrote:
>> I am not sure whether we should consider back-patching this into 9.1,
>> although that would be necessary if we wanted to fix Robert's original
>> complaint against 9.1. Thoughts?
> I guess my feeling would be "no", becau
Bruce Momjian writes:
> On Tue, Apr 10, 2012 at 06:16:31PM -0400, Robert Haas wrote:
>> On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane wrote:
>>> The way the function is coded, it has no need to look into pg_tablespace
>>> as such, which is why you don't get something like "no such tablespace".
>> I
On 04/10/2012 01:33 PM, Robert Haas wrote:
I also think that people were more receptive to my reviews before I
got a commit bit.
That's not true; many people were just as annoyed at you back then.
(Robert knows I'm kidding. I hope.)
--
Greg Smith 2ndQuadrant USg...@2ndquadrant.com
On 10 April 2012 23:07, Greg Smith wrote:
> On 04/10/2012 12:27 PM, Tom Lane wrote:
> I am doing more sophisticated things with it, so I'll celebrate this as my
> opportunity to say I did something you didn't see coming for 2012.
This is why I requested that we expose the query_id hash value - I
On Tue, Apr 10, 2012 at 06:16:31PM -0400, Robert Haas wrote:
> On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> The new pg_tablespace_location() function added in PG 9.2 to remove the
> >> director location from pg_tablespace returns an odd error for '0', which
> >>
On Tue, Apr 10, 2012 at 5:20 PM, Tom Lane wrote:
> Christoph Berg writes:
>> Re: Tom Lane 2012-04-04 <28647.1333558...@sss.pgh.pa.us>
>>> Now, Scott's comment seems to me to offer a principled way out of this:
>>> if we define the intended semantics of search_path as being similar
>>> to the trad
On Tue, Apr 10, 2012 at 5:43 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> The new pg_tablespace_location() function added in PG 9.2 to remove the
>> director location from pg_tablespace returns an odd error for '0', which
>> is InvalidOID:
>
> Well, it's the same "odd error" you'd get for any o
On Tue, Apr 10, 2012 at 05:43:12PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > The new pg_tablespace_location() function added in PG 9.2 to remove the
> > director location from pg_tablespace returns an odd error for '0', which
> > is InvalidOID:
>
> Well, it's the same "odd error" you'd g
On 04/10/2012 12:27 PM, Tom Lane wrote:
Changing the column name will definitely break
anything more specific than "select * from pg_stat_statements".
However, it's less clear that changing the units in which the column is
expressed will break things. It seems likely to me that nobody out
there
Bruce Momjian writes:
> The new pg_tablespace_location() function added in PG 9.2 to remove the
> director location from pg_tablespace returns an odd error for '0', which
> is InvalidOID:
Well, it's the same "odd error" you'd get for any other bogus OID.
The way the function is coded, it has no
Christoph Berg writes:
> Re: Tom Lane 2012-04-04 <28647.1333558...@sss.pgh.pa.us>
>> Now, Scott's comment seems to me to offer a principled way out of this:
>> if we define the intended semantics of search_path as being similar
>> to the traditional understanding of Unix PATH, then it's not an err
On Tue, Apr 10, 2012 at 11:07 AM, Merlin Moncure wrote:
> I agree that JNI isn't required -- we're going to
> have to study the pl/java system a bit to determine the best way to
> hook in. This could end up getting us into the 'biting of more than
> can chew' territory admittedly, but Atri is en
The new pg_tablespace_location() function added in PG 9.2 to remove the
director location from pg_tablespace returns an odd error for '0', which
is InvalidOID:
test=> select pg_tablespace_location(0);
ERROR: could not read symbolic link "pg_tblspc/0": No such file or
direc
On Mon, 2012-04-09 at 23:12 -0400, Christopher Browne wrote:
> But there is also a flip side to that, namely that if we do so, there
> ought to be some aspect to the process to help guide those items that
> *aren't* particularly close to being committable.
I have benefited immensely from review of
On Friday, April 6, 2012, Thom Brown wrote:
> Hi,
>
> I've tried out pg_receivexlog and have noticed that when restarting
> the cluster, pg_receivexlog gets cut off... it doesn't keep waiting.
> This is surprising as the DBA would have to remember to start
> pg_receivexlog up again.
>
>
This is in
On Tue, Apr 10, 2012 at 2:49 PM, Peter Geoghegan wrote:
> Well, I was really pointing out that people are somewhat forced into a
> corner by the current state of affairs, because committers are not
> typically able to look at anything in sufficient detail that isn't
> "ready for committer", partic
On 10/04/12 21:27, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
Yes, that would be ideal, even though not backwards-compatible.
Back-patching is out of the question, but do we want to change trigger
functions to receive dictionaries in NEW?
Hm, I was not thinking of this as being
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> On 10/04/12 20:47, Tom Lane wrote:
>> On reflection, can't we fix this as follows: if the value coming in from
>> Python is a string, just feed it to record_in, the same as we used to.
>> When I traced through the logic before, it seemed like it was faili
On 10/04/12 20:47, Tom Lane wrote:
I wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
Now that I understand what's been going on, I'll try to think of a
non-invasive way of fixing that...
ISTM that conversion of a composite value to Python ought to produce a
dict, now that the other directio
Peter Geoghegan writes:
> On 10 April 2012 18:28, Robert Haas wrote:
>> I don't agree with that. I think that there are a few people who
>> don't now have commit bits who should be given them - in particular,
>> Fujii Masao and Kevin Grittner, both of whom have been doing
>> consistently excelle
On 10 April 2012 18:28, Robert Haas wrote:
> If we accept your argument that some
> people simply cannot help themselves, then the only solution is to
> make it cease to be a prisoner's dilemma, and that can only be done by
> changing the incentives, which presumably means handing down
> punishmen
I wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> Now that I understand what's been going on, I'll try to think of a
>> non-invasive way of fixing that...
> ISTM that conversion of a composite value to Python ought to produce a
> dict, now that the other direction expects a dict. I can see
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> On 10/04/12 04:20, Tom Lane wrote:
>>> Don't know if anybody noticed bug #6559
>>> http://archives.postgresql.org/pgsql-bugs/2012-03/msg00180.php
> So, I know what's going on, I still don't know what's the best way to
> handle it.
> The function that
Robert Haas writes:
> On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane wrote:
>> The business about underlying microseconds is maybe not so good, but
>> I don't think we want to touch that right now. In the long run
>> I think it would make sense to converge on float8 msec as being the
>> standard for
On Tue, Apr 10, 2012 at 02:01:02PM -0400, Robert Haas wrote:
> On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane wrote:
> >>> Huh? I understood what you said upthread to be that we have two ways
> >>> in existing releases (an
On Tue, Apr 10, 2012 at 1:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane wrote:
>>> Huh? I understood what you said upthread to be that we have two ways
>>> in existing releases (anything unreleased has zero standing in this
>>> discussion): float8 sec
Robert Haas writes:
> On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane wrote:
>> Huh? I understood what you said upthread to be that we have two ways
>> in existing releases (anything unreleased has zero standing in this
>> discussion): float8 sec in pg_stat_statements.total_time, and
>> int8 msec ever
Hi,
2012-04-10 16:55 keltezéssel, Michael Meskes írta:
On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote:
Only a non-decorated cursor can be overridden, even if
a different default readahead window size is specified with
e.g. "ecpg -R 8". If ECPGFETCHSZ is not present, 8 will be used,
Hey,
Just a reminder that the CFP for PgNext in Denver is still open. Let's
get those talks in folks!
https://www.postgresqlconference.org/
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Developmen
On Tue, Apr 10, 2012 at 1:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 10, 2012 at 12:11 PM, Tom Lane wrote:
>>> Well, FWIW I vote for making the new columns be float8 msec.
>
>> Ugh. So the three ways of doing timing that we have already aren't
>> enough, and we need a fourth on
Robert Haas writes:
> On Tue, Apr 10, 2012 at 12:11 PM, Tom Lane wrote:
>> Well, FWIW I vote for making the new columns be float8 msec.
> Ugh. So the three ways of doing timing that we have already aren't
> enough, and we need a fourth one? Ack!
Huh? I understood what you said upthread to be
On tis, 2012-04-03 at 22:34 -0700, Josh Kupershmidt wrote:
> I noticed psql's tab-completion for 'WITH' is a bit overeager. If you
> try to tab-complete commands like:
> ALTER ROLE jsmith WITH [TAB]
> COPY tbl FROM 'filename' WITH [TAB]
>
> you'll get 'RECURSIVE' unhelpfully filled in. I think
On Tue, Apr 10, 2012 at 12:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> No matter what we end up doing here it will be consistent with
>> something; I am reminded of the phrase "the good thing about standards
>> is that there are so many to choose from...".
>
> Well, FWIW I vote for making the
On Tue, Apr 10, 2012 at 1:27 PM, Greg Smith wrote:
> There's no reward for anyone in the PostgreSQL community to be a bad guy.
> If you're too aggressive about it, submitters get mad; too loose, and you
> get both committers and people worried about the release schedule mad. And
> the community
On Tue, Apr 10, 2012 at 12:28 PM, Peter Geoghegan wrote:
> I think that you may be missing the greater point here. The people
> that do this are kind of like the defectors in prisoner's dilemma - at
> a certain point, some people cannot resist the temptation to push
> their own patch forward at th
On 04/09/2012 11:12 PM, Christopher Browne wrote:
It seems as though we need to have a "bad guy" that will say, "that
sure isn't ready to COMMIT, so we'd better step back from imagining
that it ought to be completed as part of this COMMITfest."
There's no reward for anyone in the PostgreSQL co
On 4/9/12 6:12 PM, Jeff Davis wrote:
On Mon, 2012-04-09 at 17:42 -0500, Jim Nasby wrote:
Dumb question... should operations in the various StrongLock functions
take place in a critical section? Or is that already ensure outside of
these functions?
Do you mean CRITICAL_SECTION() in the postgres
Re: Tom Lane 2012-04-04 <28647.1333558...@sss.pgh.pa.us>
> Now, Scott's comment seems to me to offer a principled way out of this:
> if we define the intended semantics of search_path as being similar
> to the traditional understanding of Unix PATH, then it's not an error
> or even unexpected to ha
On 10/04/12 07:35, Jan Urbański wrote:
On 10/04/12 04:20, Tom Lane wrote:
Don't know if anybody noticed bug #6559
http://archives.postgresql.org/pgsql-bugs/2012-03/msg00180.php
I've confirmed that the given test case works in 9.0 but fails in
9.1 and HEAD.
So, I know what's going on, I still
Tom Lane wrote:
> "Kevin Grittner" writes:
>> One other sort of mechanical test which I think can and should be
>> applied to patches submitted to the last CF is that if *at the
>> start of the CF* the patch doesn't apply, compile, pass
>> regression tests, and demonstrably provide the functional
Robert Haas writes:
> ... It's surprisingly easy to hoodwink even
> experienced contributors into thinking that your patch is really,
> really almost done, honest, it just needs a couple more tweaks when in
> fact it's nowhere close. I try not to attribute to bad faith what can
> be explained by
"Kevin Grittner" writes:
> One other sort of mechanical test which I think can and should be
> applied to patches submitted to the last CF is that if *at the start
> of the CF* the patch doesn't apply, compile, pass regression tests,
> and demonstrably provide the functionality claimed for the pat
On Tue, Apr 10, 2012 at 18:27, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Apr 10, 2012 at 17:58, Robert Haas wrote:
>>> On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane wrote:
Given that we've whacked pg_stat_statements' behavior around rather
thoroughly in this release, maybe we
On 10 April 2012 16:51, Robert Haas wrote:
> When these things are pointed out to the people who are doing them,
> the response is often either (a) this feature is so important we're
> all going to die if it's not in the release how can you even think
> about bouncing it or (b) I'm not really stil
Magnus Hagander writes:
> On Tue, Apr 10, 2012 at 17:58, Robert Haas wrote:
>> On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane wrote:
>>> Given that we've whacked pg_stat_statements' behavior around rather
>>> thoroughly in this release, maybe we could get away with redefining
>>> total_time as being
On Tue, Apr 10, 2012 at 17:58, Robert Haas wrote:
> On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Hmm. So, on further review, this is not as simple as it seems. I'd
>>> like some input from other people on what we should do here.
>>
>>> pg_stat_statements has lon
Robert Haas writes:
> No matter what we end up doing here it will be consistent with
> something; I am reminded of the phrase "the good thing about standards
> is that there are so many to choose from...".
Well, FWIW I vote for making the new columns be float8 msec. If you
don't want to change t
On Tue, Apr 10, 2012 at 10:36 AM, Tom Lane wrote:
> Atri Sharma writes:
>> On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane wrote:
>>> Hm? SPI doesn't know anything about Java either.
>
>> We plan to call SQL through SPI from the FDW,which in turn would call
>> the Pl/Java routine.
>
> If you're sayin
On Tue, Apr 10, 2012 at 10:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> Hmm. So, on further review, this is not as simple as it seems. I'd
>> like some input from other people on what we should do here.
>
>> pg_stat_statements has long exposed a column called "total_time" as a
>> float8. It
On 04/10/2012 11:36 AM, Tom Lane wrote:
Atri Sharma writes:
On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane wrote:
Hm? SPI doesn't know anything about Java either.
We plan to call SQL through SPI from the FDW,which in turn would call
the Pl/Java routine.
If you're saying that every Java functi
On 10 April 2012 16:40, Heikki Linnakangas
wrote:
> On 10.04.2012 18:31, Jeff Janes wrote:
>> If I do "select count(distinct bid) from pgbench_accounts" I get many
>> calls to btint4fastcmp, but if I do "create index on pgbench_accounts
>> (bid)" I instead get many calls to btint4cmp. If the inde
On Tue, Apr 10, 2012 at 11:24 AM, Peter Geoghegan wrote:
> On 10 April 2012 15:26, Kevin Grittner wrote:
>> A patch on which the author is continuing to work even in the absence of
>> review
>> should be considered a WIP "want feedback" submission; it should not
>> be allowed to constitute a "pl
On 10.04.2012 18:31, Jeff Janes wrote:
On Mon, Apr 9, 2012 at 11:27 PM, Heikki Linnakangas
wrote:
On 10.04.2012 03:32, Jeff Janes wrote:
The To Do wiki says not to add things to the page with discussing here.
...
sort_support was implemented for plain tuple sorting only, To Do is
extend
2012-04-10 17:34 keltezéssel, Michael Meskes írta:
On Tue, Apr 10, 2012 at 05:24:55PM +0200, Boszormenyi Zoltan wrote:
OK. Next question: now that both patches are intended to be applied,
should I send a unified single patch that contains the previous functionality
and the required fixes or a ne
Atri Sharma writes:
> On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane wrote:
>> Hm? SPI doesn't know anything about Java either.
> We plan to call SQL through SPI from the FDW,which in turn would call
> the Pl/Java routine.
If you're saying that every Java function that the FDW needs would have
to b
On Tue, Apr 10, 2012 at 05:24:55PM +0200, Boszormenyi Zoltan wrote:
> OK. Next question: now that both patches are intended to be applied,
> should I send a unified single patch that contains the previous functionality
> and the required fixes or a new one that only contains the last required
> fi
On Mon, Apr 9, 2012 at 11:27 PM, Heikki Linnakangas
wrote:
> On 10.04.2012 03:32, Jeff Janes wrote:
>>
>> The To Do wiki says not to add things to the page with discussing here.
...
>
>> sort_support was implemented for plain tuple sorting only, To Do is
>> extend to index-creation sorts (item 2 f
On Tue, Apr 10, 2012 at 8:55 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> ... We have to invoke java and there
>> are two basic ways to tie into the java runtime: one is to jump
>> through SPI via the SQL executor. The other is JNI into the pl/java
>> jvm which I think you were hinting was t
On Tue, Apr 10, 2012 at 11:25 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> ... We have to invoke java and there
>> are two basic ways to tie into the java runtime: one is to jump
>> through SPI via the SQL executor. The other is JNI into the pl/java
>> jvm which I think you were hinting was
2012-04-10 16:55 keltezéssel, Michael Meskes írta:
On Tue, Apr 10, 2012 at 10:37:22AM -0400, Noah Misch wrote:
Only a non-decorated cursor can be overridden, even if
a different default readahead window size is specified with
e.g. "ecpg -R 8". If ECPGFETCHSZ is not present, 8 will be used,
if EC
Merlin Moncure writes:
> ... We have to invoke java and there
> are two basic ways to tie into the java runtime: one is to jump
> through SPI via the SQL executor. The other is JNI into the pl/java
> jvm which I think you were hinting was the better approach.
Hm? SPI doesn't know anything abou
On 10 April 2012 15:26, Kevin Grittner wrote:
> A patch on which the author is continuing to work even in the absence of
> review
> should be considered a WIP "want feedback" submission; it should not
> be allowed to constitute a "placeholder" for inclusion in the
> release.
To be fair, I doubt
On Tue, Apr 10, 2012 at 7:27 AM, Heikki Linnakangas
wrote:
> I think the way we'd speed up COUNT(*) further would be to implement
> materialized views. Then you could define a materialized view on COUNT(*),
> and essentially get a row counter similar to MyISAM. I think it's fair to
> mark this as
On Tue, Apr 10, 2012 at 9:47 AM, Andrew Dunstan wrote:
> I don't understand what the heck you're talking about, TBH. From a user
> perspective there is nothing to work out. It will look like any other FDW.
yes, that is correct.
> The implementor of the FDW handler will have to work out the glue
1 - 100 of 123 matches
Mail list logo
