Stefan Weiss wrote:
>
> - running this query -
>
> SELECT name
> FROM dossier_contact_v
> WHERE dossier_id = 56993
>AND ctype = 234
> UNION
> SELECT name
> FROM dossier_contact_v
> WHERE dossier_id = -1
>AND ctype = -1
> ORDER BY ctype;
>
>
Morning...
What is the fastest way to achieve natural ordering from queries?
I found a function at:
http://2kan.tumblr.com/post/361326656/postgres-natural-ordering
But it increases the query time from around 0.4msecs to 74msecs...
Might be not much if occasional queries are made..but I use it f
On 2011-12-17 10:02, Andreas Kretschmer wrote:
> Stefan Weiss wrote:
>>
>> SELECT name
>> FROM dossier_contact_v
>> WHERE dossier_id = 56993
>>AND ctype = 234
>> UNION
>> SELECT name
>> FROM dossier_contact_v
>> WHERE dossier_id = -1
>>AND cty
If you use btrsort(column) from the example, you can just create a
functional index on this expression.
CREATE INDEX mytable_column_btrsort_idx ON mytable( btrsort(column) );
this can help.
2011/12/17 Richard Klingler :
> Morning...
>
> What is the fastest way to achieve natural ordering fro
As always I respect your insights - Adrian. I do understand what I did wrong
in my first attempt at getting my statement to work. But it is either over my
head or there is something missing. Where is the "from" in
select now()?
I have been using similar SQL statements for years. I never ques
On Saturday, December 17, 2011 8:50:52 am John Fabiani wrote:
> As always I respect your insights - Adrian. I do understand what I did
> wrong in my first attempt at getting my statement to work. But it is
> either over my head or there is something missing. Where is the "from" in
> select now()
>From is not required if you use literals or function results (with literal
>input parameters). If you reference something that is not one of these it has
>to come from somewhere and that location is the from/join part of the query.
In your query foo.work_date is not a literal or function and s
Hi,
>I see. So this has to do with the union; after combining the two
>queries, the tables from the FROM clauses are no longer available.
this has nothing to do with the UNION, but with the fact that the result
set is ordered after being produced, so you can order by any of its
elements, and only
Hi
>From is not required if you use literals or function results (with literal
> input parameters).
If you came from Oracle you could simply think that the "FROM DUAL" bit can
be omitted in Postgresql. There may be small differences, but that is the
basic idea.
Bèrto
--
==
On 2011-12-17 22:36, Bèrto ëd Sèra wrote:
>>I see. So this has to do with the union; after combining the two
>>queries, the tables from the FROM clauses are no longer available.
>
> this has nothing to do with the UNION, but with the fact that the result
> set is ordered after being produced, so y
Hi
> For normal (non-union) queries, this is possible:
>
Yes, you are correct. My bad.
Bèrto
--
==
If Pac-Man had affected us as kids, we'd all be running around in a
darkened room munching pills and listening to repetitive music.
On Saturday, December 17, 2011 2:21:30 pm Stefan Weiss wrote:
>
> I know, but the problem only occurs when I want to sort by a column
> which hasn't been selected, and thus cannot be referred to by its index.
> For normal (non-union) queries, this is possible:
>
> SELECT relname
> FROM
On Dec 17, 2011, at 2:21 PM, Stefan Weiss wrote:
> I know, but the problem only occurs when I want to sort by a column
> which hasn't been selected, and thus cannot be referred to by its index.
> For normal (non-union) queries, this is possible:
>
>SELECT relname
> FROM pg_class
> WH
13 matches
Mail list logo
