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 would be good if the Python pundits around
Bruce Momjian writes:
> Tom Lane wrote:
>> Still, I don't much like this solution. I agree with Heikki:
>> let's just fix it.
> Agreed, fixing it is better than trying to document/report odd behavior.
> There was talk about making pg_start_backup do an immediate checkpoint
> but there was some
Tom Lane wrote:
> I wrote:
> > Bruce Momjian writes:
> >> + ereport(NOTICE,
> >> + (errmsg("performing checkpoint")));
>
> > You've *got* to be kidding.
>
> Sigh. I have to apologize for that over-hasty complaint: I misread
> where you intended to put the messa
Tom Lane wrote:
> I wrote:
> > Bruce Momjian writes:
> >> + ereport(NOTICE,
> >> + (errmsg("performing checkpoint")));
>
> > You've *got* to be kidding.
>
> Sigh. I have to apologize for that over-hasty complaint: I misread
> where you intended to put the messa
Tom Lane wrote:
> Alvaro Herrera writes:
> > So there's a minor issue on Takahiro-san fillfactor-on-toast patch,
> > which is that it does not hand out the last possible "kind" value. This
> > is a bits32 field, so at least theoretically on some platforms it will
> > be wider than 32 while on oth
Martin Pihlak writes:
> Hmm, this is a problem -- "\dX *.*" now shows all objects, and there is
> no way to list only user objects. This is especially a problem if user
> objects are scattered in different schemas.
I don't find this to be a pressing problem. If the user has lots of
schemas, they
Andrew Gierth writes:
> Happened to notice this while looking for something else; the \ef
> command appears to be missing from \? output. Suggested patch below.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Alvaro Herrera writes:
> So there's a minor issue on Takahiro-san fillfactor-on-toast patch,
> which is that it does not hand out the last possible "kind" value. This
> is a bits32 field, so at least theoretically on some platforms it will
> be wider than 32 while on others it will be exactly 32.
So there's a minor issue on Takahiro-san fillfactor-on-toast patch,
which is that it does not hand out the last possible "kind" value. This
is a bits32 field, so at least theoretically on some platforms it will
be wider than 32 while on others it will be exactly 32. I'm wondering
if this is the c
On Fri, Apr 3, 2009 at 4:46 PM, Tom Lane wrote:
>
> I don't think there's a whole lot of choice in the matter. We have to
> patch this, and put in the next release notes "if you have any hash
> indexes on interval columns, REINDEX them after updating". Does anyone
> see it differently, or have s
Simon Riggs writes:
> However, the basic premise is that idle-in-transaction sessions do not
> need to block index builds.
[ thinks for awhile... ] Actually, I believe that your premise is
correct; the problem is with your proof ;-). Considering only the
xmins is insufficient to prove that this
The present implementation of interval_hash() is very carefully designed
and coded ... to meet the wrong specification :-(. What it should
be doing is producing equal hashcodes for values that interval_eq()
considers equal. The error is exhibited in the recent bug report #4748.
Attached is a pro
On 3 Apr 2009, at 19:44, Lawrence, Ramon wrote:
I would be especially interested in using a shared memory hash table
that *all* backends can use - if the table is mostly read-only, as
dimension tables often are in data warehouse applications. That
would
give zero startup cost and significantl
On Fri, 2009-04-03 at 15:46 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > No need to wait for idle-in-transaction sessions during index builds.
> > GetCurrentVirtualXIDs() specifically *includes* backends that have
> > proc->xmin == InvalidTransactionId (0), but I'm not sure why.
>
> On furth
Robert Haas writes:
> On Fri, Apr 3, 2009 at 4:29 PM, Tom Lane wrote:
>> Correct, but you've got the details all wrong. The real problem is that
>> the planner might discard a join path hash(A,B) at level 2 because it
>> loses compared to, say, merge(A,B). But when we get to level three,
>> per
On Fri, Apr 3, 2009 at 4:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> I don't see why hash_inner_and_outer can't walk the outer path looking
>> for suitable hashes to reuse. I think the question is how aggressive
>> we want to be in performing that search.
>
> Correct, but you've got the deta
Alvaro Herrera writes:
> ... but I don't really see that this buys much of anything. I think a
> better answer to this kind of problem would be
> + Assert(IsA(def, ReloptElem));
Well, that will help to make wrong-node-type mistakes more obvious (at
least if you're running an assert-enabled
Alvaro Herrera writes:
>> Well, you could still have separate productions that did or didn't allow
>> qualified names there (or perhaps better, have the code in
>> functioncmds.c reject qualified names). I think the use of two different
>> node types is going to result in duplicate coding and/or
Alvaro Herrera escribió:
> Tom Lane escribió:
> > Well, you could still have separate productions that did or didn't allow
> > qualified names there (or perhaps better, have the code in
> > functioncmds.c reject qualified names). I think the use of two different
> > node types is going to result
Tom Lane escribió:
> Alvaro Herrera writes:
> > Tom Lane escribi�:
> >> Surely this will break other things. I find myself wondering why you
> >> invented ReloptElem at all, instead of adding a field to DefElem.
>
> > I had to, precisely because it messes up other uses of DefElem ...
>
> > For
Robert Haas writes:
> I don't see why hash_inner_and_outer can't walk the outer path looking
> for suitable hashes to reuse. I think the question is how aggressive
> we want to be in performing that search.
Correct, but you've got the details all wrong. The real problem is that
the planner migh
On Fri, Apr 3, 2009 at 12:55 PM, Greg Stark wrote:
>>> 1. When the hash is not expected to spill to disk, it preserves the
>>> pathkeys of the outer side of the join. If the optimizer were allowed
>>> to assume that, it could produce significantly more efficient query
>>> plans in some cases.
>>
Alvaro Herrera writes:
> Tom Lane escribió:
>> Surely this will break other things. I find myself wondering why you
>> invented ReloptElem at all, instead of adding a field to DefElem.
> I had to, precisely because it messes up other uses of DefElem ...
> For example, the grammar would allow
>
Tom Lane escribió:
> Alvaro Herrera writes:
> > This patch seems to be the right cure. (Some other users of
> > opt_definition remain; I think it's just CREATE FUNCTION by now).
>
> Surely this will break other things. I find myself wondering why you
> invented ReloptElem at all, instead of add
Alvaro Herrera writes:
> This patch seems to be the right cure. (Some other users of
> opt_definition remain; I think it's just CREATE FUNCTION by now).
Surely this will break other things. I find myself wondering why you
invented ReloptElem at all, instead of adding a field to DefElem.
Simon Riggs writes:
> No need to wait for idle-in-transaction sessions during index builds.
> GetCurrentVirtualXIDs() specifically *includes* backends that have
> proc->xmin == InvalidTransactionId (0), but I'm not sure why.
On further consideration, this patch is simply *wrong*, and would still
Alvaro Herrera escribió:
> Khee Chin escribió:
>
> > After some debugging in reloptions.c, I've realised that the issue is
> > caused by fillfactor not having a validnsps in transformRelOptions.
> > Adding an additional condition "&& (validnsps))" at line 595 or 612
> > appears to fix the issue.
>
Khee Chin escribió:
> After some debugging in reloptions.c, I've realised that the issue is
> caused by fillfactor not having a validnsps in transformRelOptions.
> Adding an additional condition "&& (validnsps))" at line 595 or 612
> appears to fix the issue.
No, the bug is that they are passed a
Hi,
I've noticed a difference in 8.3.7 vs 8.4 (via git branch -r)
behaviour
8.3
testdb=> create table foo (bar bigserial primary key with
(fillfactor=75));
NOTICE: CREATE TABLE will create implicit sequence "foo_bar_seq" for
serial column "foo.bar"
NOTICE: CREATE TABLE / PRIMARY KEY will
Tom Lane wrote:
> Alvaro Herrera writes:
> > It works for me now. Thanks to Euler for tracking the Python problem
> > down and to you for the commit!
>
> Hmph. I wonder what caused that crash you reported originally? The
> backtrace doesn't look like it's explained by the argument-name bug:
>
Alvaro Herrera writes:
> Tom Lane wrote:
>> Alvaro, would you see if it still crashes for you on Debian?
>> If so there's some other issue with python 2.5.4 ...
> It works for me now. Thanks to Euler for tracking the Python problem
> down and to you for the commit!
Hmph. I wonder what caused t
> > I would be especially interested in using a shared memory hash table
> > that *all* backends can use - if the table is mostly read-only, as
> > dimension tables often are in data warehouse applications. That
would
> > give zero startup cost and significantly reduced memory.
>
> I think that's
Tom Lane wrote:
> Alvaro's example now gives me this on Fedora 10:
>
> ERROR: PL/Python: PL/Python function "unaccent" failed
> DETAIL: : normalize() argument 2 must be
> unicode, not str
>
> which is the same as it did in 8.3. I do not know if that's a bug
> or expected (making the database
Simon Riggs wrote:
> "Read-only" isn't an isolated case. Often you find many read-only
tables
> alongside rapidly changing tables. So even the busiest of databases
can
> benefit from read-only optimisations.
> Having changes to those tables cause much heavier additional work is
OK,
> if judged
On Fri, 2009-04-03 at 18:03 +0100, Greg Stark wrote:
> I wonder if we need a whole class of index algorithms to deal
> specifically with read-only tables
I think we can drop the word "index" from the sentence as well.
"Read-only" isn't an isolated case. Often you find many read-only tables
alon
Euler Taveira de Oliveira writes:
> Alvaro Herrera escreveu:
>> I'm not sure I'm reading this right, but isn't this preventing a
>> plpytHon function to work if parameters don't have names assigned?
> No. See the proc->argnames test before PyDict_SetItemString(). The other test
> is just tighteni
On Fri, Apr 3, 2009 at 5:41 PM, Simon Riggs wrote:
>
> I would be especially interested in using a shared memory hash table
> that *all* backends can use - if the table is mostly read-only, as
> dimension tables often are in data warehouse applications. That would
> give zero startup cost and sign
>> 1. When the hash is not expected to spill to disk, it preserves the
>> pathkeys of the outer side of the join. If the optimizer were allowed
>> to assume that, it could produce significantly more efficient query
>> plans in some cases.
>
> This is definitely possible, but you will have to dynam
On Thu, 2009-04-02 at 22:08 -0400, Robert Haas wrote:
> 3. Avoid building the exact same hash table twice in the same query.
> This happens more often you'd think. For example, a table may have
> two columns creator_id and last_updater_id which both reference person
> (id). If you're considerin
Josh Berkus writes:
> The other "existing" bugs I think relate to extreme corner cases (e.g.
> ENUMs of DOMAINS) and/or may be feature requests rather than bugs (e.g.
> Cover Density Ranking) so I think can safely be put off until 8.4.1 or
> later.
As far as the polymorphic-functions-vs-domain
On Fri, Apr 3, 2009 at 11:24 AM, Lawrence, Ramon wrote:
> I would be interested in working with you on any of these changes to
> hash join if you decide to pursue them. I am especially interested in
> looking at the hash aggregation code and potentially improving its
> efficiency.
Wow, that wou
--On Freitag, April 03, 2009 08:30:14 +0300 Heikki Linnakangas
wrote:
The first looks nicer, IMHO, because the word 'lazy' makes it
self-documenting. In the second form, you have to look at the manual to
figure out what the 2nd argument does.
Regarding that many catalog functions are already
Teodor Sigaev writes:
>> Here is a test case that crashes even with the patch:
> I was too optimistic :(
> Attached patch contains:
> - changes in R-tree picksplit methods. Now it checks bad ratio and if so then
>use simple split: one half of entries to one page, and another part - to
>a
> While investigating some performance problems recently I've had cause
> to think about the way PostgreSQL uses hash joins. So here are a few
> thoughts. Some of these have been brought up before.
>
> 1. When the hash is not expected to spill to disk, it preserves the
> pathkeys of the outer si
Magnus Hagander writes:
> Tom Lane wrote:
>> In view of the way that canonicalize_path() works, I can't help thinking
>> this is going in precisely the wrong direction.
> In a way, yes. But canonicalize_path() runs only in the backend, and
> this is only in the frontend. I think the requirements
On Fri, Apr 03, 2009 at 08:03:33AM -0400, Robert Haas wrote:
> On Fri, Apr 3, 2009 at 1:48 AM, Heikki Linnakangas
> wrote:
> > Robert Haas wrote:
> >>
> >> While investigating some performance problems recently I've had cause
> >> to think about the way PostgreSQL uses hash joins. ?So here are a f
Heikki Linnakangas writes:
> Rather than deplore that you can't expedite the checkpoint, why don't we
> just make it possible?
+1
> The first question is what the default behavior should be? We've seen
> enough complaints and I've been bitten by that myself during development
> of other stuff
I wrote:
> Bruce Momjian writes:
>> +ereport(NOTICE,
>> +(errmsg("performing checkpoint")));
> You've *got* to be kidding.
Sigh. I have to apologize for that over-hasty complaint: I misread
where you intended to put the message. (Seems like there is too
Here is a test case that crashes even with the patch:
I was too optimistic :(
Attached patch contains:
- changes in R-tree picksplit methods. Now it checks bad ratio and if so then
use simple split: one half of entries to one page, and another part - to
another page.
- protection from buggy
Because your vacation responder is even more broken than that. It
sends the mail to the *From* header address instead of the envelope
from. Aside from not handling mailing lists sanely that also makes it
susceptible to mail loops.
--
Greg
On 3 Apr 2009, at 04:40, Zeugswetter Andreas OSB s
On Fri, Apr 3, 2009 at 1:48 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>>
>> While investigating some performance problems recently I've had cause
>> to think about the way PostgreSQL uses hash joins. So here are a few
>> thoughts. Some of these have been brought up before.
>>
>> 1. When
HI All,
I had gone through advantages of visibilitymap along with discussion on
thick index. I have a question.
when we have information about visibility of the data, does it make sense to
propagate values of expression stored in index through various slots of
execution tree?
It would be helpful w
Hi,
> We've discussed before the idea that NOT NULL constraints should be
> explicitly represented in pg_constraint, just like general CHECK
> constraints (this would allow them to be named, have sane inheritance
> behavior, etc). If we had that, then pg_attribute.attnotnull could
> indicate the
> Could the list admin please unsubscribe Andreas Zeugswetter from the
> lists until he can fix his vacation-responder-gone-nuts?
I am very sorry, fixed. I forgot to set nomail before setting the out of office
assistant
which my company requires me to do in this braindead way.
But I assume Exch
Vlad Arkhipov wrote:
> Is it possible to print which key value is duplicated when 'Duplicate
> key value violates unique constraint' occurs? Foreign key violation
> error reports such kind of information.
I think it is not difficult from a technical standpoint.
The attached patch adds DETAIL
Bruce Momjian wrote:
> I have applied a simplified version of your patch, attached, that adds
> just a "AND <>" line to the query; I was a little concerned that IN
> might affect performance, and the macros seemed kind of complicated.
>
Thanks.
> Also, since my patch this morning any pattern w
56 matches
Mail list logo
