On Sun, Feb 8, 2009 at 6:34 PM, Tom Lane wrote:
> It's possible that there are specific cases where the UNION optimization
> checks could allow domains to be treated as their base types, but
> blindly smashing both sides of the check to base is going to break more
> cases than it fixes.
What my
> "Tom" == Tom Lane writes:
> Andrew Gierth writes:
>> Type-dependent selection of operators has already been done as
>> part of parse analysis, no? And the domain -> base conversion is
>> purely a relabelling, no? So what semantic change is possible as a
>> result?
Tom> Domain conver
Andrew Gierth writes:
> Type-dependent selection of operators has already been done as part of
> parse analysis, no? And the domain -> base conversion is purely a
> relabelling, no? So what semantic change is possible as a result?
Domain conversions are *not* simply relabellings. It's possible n
> "Tom" == Tom Lane writes:
[domain -> base type conversion interfering with optimization]
Tom> You seem to be laboring under the delusion that this is
Tom> considered a bug.
Of course it's a bug, or at least a missing feature - there is no
justification for putting performance deathtrap
and frankly I still (and few others) think it is a defect, for domain
with some base type should be treated as such. It is after all treated
that way when you create index.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://w
On Sat, Feb 7, 2009 at 5:39 PM, Tom Lane wrote:
>
> You seem to be laboring under the delusion that this is considered a
> bug. It's a necessary semantic restriction, because the pushed-down
> expression could mean different things when applied to different
> data types.
Very true Tom, still I w
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
> with a little help on Irc from Andrew (RhodiumToad) I got it 'fixed',
> but I know this is just a hack:
You seem to be laboring under the delusion that this is considered a
bug. It's a necessary semantic restriction, because the pushed-down
expressi
so Tom,
with a little help on Irc from Andrew (RhodiumToad) I got it 'fixed',
but I know this is just a hack:
Index: src/backend/utils/adt/selfuncs.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/selfuncs.c,v
retrieving
On Fri, Feb 6, 2009 at 9:50 PM, Tom Lane wrote:
> The UNION arms have to all be the same data type in order to have
> restrictions pushed down through the UNION. You did not show us
> the table declarations for your first example, but I bet that updateid
> isn't the same type in both. (And yes,
that helped, thanks a lot Tom.
Looks like additional thing on 'pet peeves' list (from -general).
:P
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
=?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
> so my question is, why isn't postgres use index on some tables , and
> search for the X > N individually ?
The UNION arms have to all be the same data type in order to have
restrictions pushed down through the UNION. You did not show us
the table de
On Fri, Feb 6, 2009 at 6:20 PM, Grzegorz Jaśkiewicz wrote:
> On Fri, Feb 6, 2009 at 6:15 PM, Robert Haas wrote:
>> Just guessing here, but what values are you using for
>> join_collapse_limit and from_collapse_limit, and what happens if you
>> make them much bigger (like 100)?
changing them to 1
On Fri, Feb 6, 2009 at 6:15 PM, Robert Haas wrote:
> Just guessing here, but what values are you using for
> join_collapse_limit and from_collapse_limit, and what happens if you
> make them much bigger (like 100)?
both default values, afair = 8.
--
Sent via pgsql-performance mailing list (pgsql-
Just guessing here, but what values are you using for
join_collapse_limit and from_collapse_limit, and what happens if you
make them much bigger (like 100)?
...Robert
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.po
Hey folks,
I have few tables, that inherit from table X.
The query I perform, tries to obtain information about changes in all
tables that inherit from X,
aside from that, I have table Y that keeps another information related
to changes, but in bit different schema.
Anyway, there is one unique id
15 matches
Mail list logo
