Tom Lane píše v ne 05. 04. 2009 v 17:44 -0400:
> Zdenek Kotala writes:
> > Zdenek Kotala píše v út 31. 03. 2009 v 21:25 +0200:
> >> Another possibility is to rewrite postgres(and pg_resetxlog) to use
> >> getopt_long() instead of getopt().
>
> > Attached patch rewrites postgres to use getopt_lon
Robert Haas writes:
> (It's also worth pointing out that the calculations we do with
> ndistinct are pretty approximations anyway. If the difference between
> stadistinct = -1 x 10^-6 and stadistinct = -1.4^10-6 is the thing
> that's determining whether the planner is picking the correct plan on
On Sun, Apr 5, 2009 at 10:38 PM, Robert Haas wrote:
> On Sun, Apr 5, 2009 at 10:00 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Sun, Apr 5, 2009 at 7:56 PM, Tom Lane wrote:
[ shrug... ] Precision is not important for this value: we are not
anywhere near needing more than six sig
On Sun, Apr 5, 2009 at 10:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Apr 5, 2009 at 7:56 PM, Tom Lane wrote:
>>> [ shrug... ] Precision is not important for this value: we are not
>>> anywhere near needing more than six significant digits for our
>>> statistical estimates. Range,
Robert Haas writes:
> On Sun, Apr 5, 2009 at 7:56 PM, Tom Lane wrote:
>> [ shrug... ] Precision is not important for this value: we are not
>> anywhere near needing more than six significant digits for our
>> statistical estimates. Range, on the other hand, could be important
>> when dealing wi
On Sun, Apr 5, 2009 at 7:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Apr 4, 2009 at 11:14 PM, Tom Lane wrote:
>>> * Using an integer is bogus. Use a float4 and forget the weird scaling;
>>> it should have exactly the same interpretation as stadistinct, except
>>> for 0 meaning "unse
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I think the objection that is most likely to be raised is that it would
> confuse or break programs that analyze EXPLAIN output in any degree of
> detail. Of course such programs are going to need some work for 8.4
> already.
As someone who
Teodor Sigaev writes:
>> I don't like throwing an error there; I wish there were a way for the
>> generic code to apply the fallbackSplit code instead. I see that
>> in this particular formulation it's dependent on the datatype ---
>> can we get around that, by having it invoke the union method?
On Sun, Apr 05, 2009 at 08:55:07PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
> >> The \df thing? That's something it'd be okay to revisit during
> >> beta, IMHO.
>
> > OK, I'll work on this tomorrow :)
>
> I think what we were la
David Fetter writes:
> On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
>> The \df thing? That's something it'd be okay to revisit during beta,
>> IMHO.
> OK, I'll work on this tomorrow :)
I think what we were lacking was consensus on what it should do,
not code ...
I wrote:
> Peter Eisentraut writes:
>> On March 10, 2009, Tom Lane wrote:
>>> FWIW, the systemtap guys are really, really close to having a working
>>> DTrace equivalent for Linux:
>>> http://gnu.wildebeest.org/diary/2009/02/24/systemtap-09-markers-everywhere/
>> So how is this going? Is it usab
On Sun, Apr 05, 2009 at 02:07:32PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Sun, Apr 05, 2009 at 12:21:41PM -0400, Tom Lane wrote:
> >> I will leave that item on the Open Items list. I take it no one's
> >> excited about the others?
>
> > When the windowing functions become a pain po
Robert Haas writes:
> On Sat, Apr 4, 2009 at 11:14 PM, Tom Lane wrote:
>> * Using an integer is bogus. Use a float4 and forget the weird scaling;
>> it should have exactly the same interpretation as stadistinct, except
>> for 0 meaning "unset" instead of "unknown".
> I have a deep-seated aversi
Martin Pihlak writes:
> Tom Lane wrote:
>> I don't find this to be a pressing problem. If the user has lots of
>> schemas, they probably have lots of objects too, and are unlikely to
>> need such a thing.
> Current behaviour makes it impossible to get a quick overview of all the
> user defined o
James Pye writes:
> Any thoughts on the acceptability of a complete rewrite for Python 3?
I've always thought that plpython.c was a bit on the hackish side.
If we do decide we have to make plpython2 and plpython3 separate
languages, it'd be pretty easy to just start over with a whole new
implem
On Apr 5, 2009, at 8:54 AM, Tom Lane wrote:
Hm, did you read the link I cited? It's not so surprising that 3.0
should have broken distutils, but what I found distressing is that
they
fixed distutils and then 3.0.1 broke it *again*. I stand by my
opinion
that Python 3 isn't stable yet.
Ye
Peter Eisentraut writes:
> On Sunday 05 April 2009 05:00:04 Tom Lane wrote:
>> Is there a reason not to fix it as suggested at
>> http://archives.postgresql.org/pgsql-bugs/2009-02/msg00032.php
>> ie recode on-the-fly from database encoding to UTF8?
> Probably just verifying that it works.
I stud
Zdenek Kotala writes:
> Zdenek Kotala pÃÅ¡e v út 31. 03. 2009 v 21:25 +0200:
>> Another possibility is to rewrite postgres(and pg_resetxlog) to use
>> getopt_long() instead of getopt().
> Attached patch rewrites postgres to use getopt_long instead of getopt.
Actually, I fooled around with it l
Peter Eisentraut writes:
> On Sunday 05 April 2009 05:00:04 Tom Lane wrote:
>> Is there a reason not to fix it as suggested at
>> http://archives.postgresql.org/pgsql-bugs/2009-02/msg00032.php
>> ie recode on-the-fly from database encoding to UTF8?
> Probably just verifying that it works.
Well,
Zdenek Kotala píše v út 31. 03. 2009 v 21:25 +0200:
> Another possibility is to rewrite postgres(and pg_resetxlog) to use
> getopt_long() instead of getopt().
Attached patch rewrites postgres to use getopt_long instead of getopt.
Patch also removes configure part for Solaris related to getopt.
On Sunday 05 April 2009 05:00:04 Tom Lane wrote:
> Chris Browne writes:
> > j...@agliodbs.com (Josh Berkus) writes:
> >> This one is also really bad, but probably only Doc-patchable.
> >> However, can SQL/XML really be said to be core functionality if it
> >> only works in UTF-8?
> >> * BUG #4622:
Stephen Frost writes:
> I definitely feel that it would be best to make this change now, when
> we're introducing CTE as a type that anything doing EXPLAIN would need
> to deal with at some level anyway than to add it later (eg: 8.5). I'm
> definitely a +1 on this.
Here's a somewhat contrived ex
Greg Stark writes:
> On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas wrote:
>> I'm excited about some of them, but not to the point of not wanting to
>> ship beta. So +1 for removing them as per your suggestions.
> I'm somewhat excited about posix_fadvise but my general feeling was
> that it was be
On Sun, Apr 5, 2009 at 6:54 PM, Robert Haas wrote:
> I'm excited about some of them, but not to the point of not wanting to
> ship beta. So +1 for removing them as per your suggestions.
I'm somewhat excited about posix_fadvise but my general feeling was
that it was best to do nothing anyways. I
David Fetter writes:
> On Sun, Apr 05, 2009 at 12:21:41PM -0400, Tom Lane wrote:
>> I will leave that item on the Open Items list. I take it no one's
>> excited about the others?
> When the windowing functions become a pain point, let's revisit :)
The \df thing? That's something it'd be okay t
On Sun, Apr 05, 2009 at 12:21:41PM -0400, Tom Lane wrote:
> I will leave that item on the Open Items list. I take it no one's
> excited about the others?
When the windowing functions become a pain point, let's revisit :)
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
On Sun, Apr 5, 2009 at 12:21 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Robert Haas wrote:
>>> Well, it's a compatibility function...
>
>> compatible with what?
>
> It's required by the SQL standard.
>
>> The other thing that frankly bothers me is that we appear to have
>> acquired this func
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> This isn't terribly compelling in this example, of course, but
> it gets a lot more important when you've got a dozen of 'em.
Exactly.
> >From the perspective of the backend this is a simple and cheap change.
Awesome.
> I think the objection that is most
I wrote:
> Stephen Frost writes:
>> Erm, of course, the CTE *has* an ID already, since you name them. Could
>> we get that ID/name up into the piece of the InitPlan that is handling
>> that CTE?
> I'm not sure but will be glad to take a look. Assuming it's not
> unreasonably difficult, does any
Andrew Dunstan writes:
> Robert Haas wrote:
>> Well, it's a compatibility function...
> compatible with what?
It's required by the SQL standard.
> The other thing that frankly bothers me is that we appear to have
> acquired this function by a curious process which involved no proposal
> or di
Stephen Frost writes:
> * Stephen Frost (sfr...@snowman.net) wrote:
>> Would be nice if there was a CTE ID or similar to link between
>> the pieces of the InitPlan and the CTE nodes.
> Erm, of course, the CTE *has* an ID already, since you name them. Could
> we get that ID/name up into the piece
Marko Kreen writes:
> On 4/4/09, Tom Lane wrote:
>> So my conclusion is that Python 3.0 is much too wet behind the ears for
>> us to worry about in PG 8.4. I'd guess that we should come back to the
>> issue towards the end of 2009, and perhaps think about back-porting
>> after we have something
* Stephen Frost (sfr...@snowman.net) wrote:
> Would be nice if there was a CTE ID or similar to link between
> the pieces of the InitPlan and the CTE nodes.
Erm, of course, the CTE *has* an ID already, since you name them. Could
we get that ID/name up into the piece of the InitPlan that is handli
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Apr 5, 2009 at 9:40 AM, Robert Haas wrote:
> > I'm a bit unsatisfied with this output because it doesn't tell me the
> > plan it used to construct the CTE being scanned.
>
> I'm totally wrong. Sorry for the noise.
Eh. It could be made clear
On Sun, Apr 5, 2009 at 9:40 AM, Robert Haas wrote:
> I'm a bit unsatisfied with this output because it doesn't tell me the
> plan it used to construct the CTE being scanned.
I'm totally wrong. Sorry for the noise.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
I don't like throwing an error there; I wish there were a way for the
generic code to apply the fallbackSplit code instead. I see that
in this particular formulation it's dependent on the datatype ---
can we get around that, by having it invoke the union method?
Done. rtree.patch.gz contains pa
I'm a bit unsatisfied with this output because it doesn't tell me the
plan it used to construct the CTE being scanned.
rhaas=# explain with wumpus as (select * from foo where id < 200)
select * from foo f, wumpus c, wumpus u where f.creator_id = c.id and
f.last_updater_id = u.id;
Hellow,
I want to be more precis
I want to change the syntax as follows
Start Transaction (priority)
I have 03 transactions
I want to give to every transaction à priority
Example
Transaction 1
Start transaction (03)
.
Commit
Transaction 2
Start transaction (04)
………
Com
Hellow,
I want to be more precis
I want to change the syntax as follows
Start Transaction (priority)
I have 03 transactions
I want to give to every transaction à priority
Example
Transaction 1
Start transaction (03)
.
Commit
Transaction 2
Start transaction (04)
………
Commit
Transacti
On Sun, Apr 05, 2009 at 07:55:44AM -0400, Robert Haas wrote:
> On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan wrote:
> > Tom Lane wrote:
> >> If there are no objections, I'm going to remove the following items
> >> from the list at
> >> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
> >
Robert Haas wrote:
On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan wrote:
Tom Lane wrote:
If there are no objections, I'm going to remove the following items
from the list at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
change cardinality() for multi-dim arrays?
On Sun, Apr 5, 2009 at 7:45 AM, Andrew Dunstan wrote:
> Tom Lane wrote:
>> If there are no objections, I'm going to remove the following items
>> from the list at
>> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
>>
>>
>> change cardinality() for multi-dim arrays?
>>
>> Drop; the
Tom Lane wrote:
If there are no objections, I'm going to remove the following items
from the list at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
change cardinality() for multi-dim arrays?
Drop; there's no consensus that this should be changed
I don't think we sho
On Sat, Apr 4, 2009 at 11:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Apr 4, 2009 at 7:04 PM, Tom Lane wrote:
>>> I'm not thrilled about adding a column to pg_attribute for this.
>
>> What is the specific nature of your concern?
>
> Actually, I'm more worried about the TupleDesc data
Tom Lane wrote:
> I don't find this to be a pressing problem. If the user has lots of
> schemas, they probably have lots of objects too, and are unlikely to
> need such a thing.
Current behaviour makes it impossible to get a quick overview of all the
user defined objects. And it doesn't really ma
abdelhak benmohamed wrote:
hello,
here more of details
I have a set of transaction. Naturally, the transactions execute
themselves in competition. But I would want to give to every
transaction a priority. Thus the transaction more priority must
execute itself in first.
I thought, as
On 4/4/09, Tom Lane wrote:
> Peter Eisentraut writes:
> > I have recently fixed the configure script to recognize Python 3.0. But
> > note that building and running PL/Python with Python 3.0 does not
> > actually work. It looks like several symbols have been removed or
> > changed. It woul
hello,
here more of details
I have a set of transaction. Naturally, the transactions execute themselves in
competition. But I would want to give to every transaction a priority. Thus
the transaction more priority must execute itself in first.
I thought, as first step, to change the transac
48 matches
Mail list logo
