Re: [HACKERS] Eliminating unnecessary left joins

2007-04-08 Thread Nicolas Barbier
2007/4/7, Ottó Havasvölgyi [EMAIL PROTECTED]: My simple example: Class hierarchy and fields: Shape (ID, X, Y) | +-Circle (ID, Radius) | +-Rectangle (ID, Width, Height) The mapper creates 3 tables with the columns next to the class name. And it creates 3 views. One of them: RectangleView:

[HACKERS] problem with install scripts.

2007-04-08 Thread Tzahi Fadida
Hi, I used the development version of PostgreSQL to compile my module fulldisjunctions. The install scripts works well there (passes). However, i wanted to check if it still works (backward compatible) with the stable version and it complains on these lines in the sql script when i do make

Re: [HACKERS] Eliminating unnecessary left joins

2007-04-08 Thread Ottó Havasvölgyi
My mapper joins the parent classes' tables to the current class' table in the view. In the ShapeView only ID, X, and Y is selected from the shape table, and none of the child tables are touched, opposite to your sample. But even though all Shape objects (circles and rectangles too) are in the

Re: [HACKERS] problem with install scripts.

2007-04-08 Thread Peter Eisentraut
Tzahi Fadida wrote: What should i do? Telling what version you use and what error messages you see would help. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will

Re: [HACKERS] problem with install scripts.

2007-04-08 Thread Tzahi Fadida
On Sunday 08 April 2007 21:34:52 Peter Eisentraut wrote: Tzahi Fadida wrote: What should i do? Telling what version you use and what error messages you see would help. SET client_min_messages = warning; \set ECHO none + ERROR: unrecognized configuration parameter

Re: [HACKERS] problem with install scripts.

2007-04-08 Thread Peter Eisentraut
Tzahi Fadida wrote: On Sunday 08 April 2007 21:34:52 Peter Eisentraut wrote: Tzahi Fadida wrote: What should i do? Telling what version you use and what error messages you see would help. SET client_min_messages = warning; \set ECHO none + ERROR: unrecognized configuration

Re: [PATCHES] [HACKERS] Arrays of Complex Types

2007-04-08 Thread Andrew Dunstan
Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote: So, hum, what happened to the idea of creating the array types only on demand? Scotched, as far as I could tell, More like you submitted a patch

Re: [PATCHES] [HACKERS] Arrays of Complex Types

2007-04-08 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: One of the things that's been bothering me about this proposal is that it leaves untouched and indeed greatly expands the scope of the typename mangling we do. (i.e. adding an entry to pg_type with _ prepended). Yeah, that's been bothering me too.

Re: [PATCHES] [HACKERS] Arrays of Complex Types

2007-04-08 Thread David Fetter
On Sun, Apr 08, 2007 at 07:08:38PM -0400, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: One of the things that's been bothering me about this proposal is that it leaves untouched and indeed greatly expands the scope of the typename mangling we do. (i.e. adding an entry to

Re: [PATCHES] [HACKERS] Arrays of Complex Types

2007-04-08 Thread Andrew Dunstan
Tom Lane wrote: I've been thinking of proposing that we add a column to pg_type that points from a type to its array type (if any), ie the reverse link from typelem. If we had that then the parser could follow that to determine which type is foo[], instead of relying on the _foo naming

Re: [PATCHES] [HACKERS] Arrays of Complex Types

2007-04-08 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I don't suggest that we stop using the naming convention, but it would no longer be a hard-and-fast rule, just a convention. In particular we could rejigger things around the edges to reduce the name conflict problem. For instance the

Re: [PATCHES] [HACKERS] Arrays of Complex Types

2007-04-08 Thread Andrew Dunstan
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: I don't suggest that we stop using the naming convention, but it would no longer be a hard-and-fast rule, just a convention. In particular we could rejigger things around the edges to reduce the name conflict

Re: [PATCHES] [HACKERS] Arrays of Complex Types

2007-04-08 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: I'm slightly inclined to agree with David that the danger of catalog bloat isn't that great, and might not justify the extra work that some sort of explicit array creation would involve (e.g. changes in grammar, pg_dump), as long as we are agreed

Re: [PATCHES] [HACKERS] Arrays of Complex Types

2007-04-08 Thread Andrew Dunstan
Tom Lane wrote: Based on this, I withdraw my efficiency concern about generating rowtypes for all user tables. I do, however, still object to generating them for system tables. In particular an array type for pg_statistic will actively Not Work and probably constitute a security hole, because

Re: [HACKERS] Bitmap index thoughts (another segfault)

2007-04-08 Thread Gavin Sherry
I'm seeing a segfault on a size TPC-H size 10 database. The patch and code are: - bitmap patch from 12 Mar - 8.3 dev from 27 Mar Thanks Mark. I tracked this down. I'll post a new patch soon. Gavin ---(end of broadcast)--- TIP 6: explain

Re: [HACKERS] Bitmap index thoughts (another segfault)

2007-04-08 Thread Gavin Sherry
On Sat, 7 Apr 2007, Mark Kirkwood wrote: Mark Kirkwood wrote: bitmap=# SELECT count(*) FROM bitmaptest WHERE val1 in (1,7) AND val0 IN (4,3) ; ERROR: XX000: unknown stream type 2 LOCATION: stream_add_node, tidbitmap.c:1033 Thanks. Turned out to be a

Re: [PATCHES] [HACKERS] Arrays of Complex Types

2007-04-08 Thread Tom Lane
Andrew Dunstan [EMAIL PROTECTED] writes: How would we do that? Not create the array types in bootstrap mode? Or just special-case pg_statistic? Not generate them in bootstrap mode works for me. IIRC, there's code somewhere in there that allows anyarray to pass as a column type in bootstrap