"Alfred" <[EMAIL PROTECTED]> writes:
> CO| N
> --+---
> 0 | 15-59
> 1 | 0, 16-59
> 2 | 0-1, 17-59
> 15| 0-14, 30-59
> 16| 0-15, 31-59
> 30| 0-29, 45-59
> 31| 0-30, 46-59
> 45| 0-44
> 46| 1-45
>
Tom Lane <[EMAIL PROTECTED]> writes:
> A SQL-language function like this should get inlined into the query,
> so that you don't lose any performance compared to writing out the
> full expression each time.
I think what's going on here is that he doesn't really want a function in the
programming s
"A. Kretschmer" <[EMAIL PROTECTED]> writes:
> *untested*
> DELETE FROM partner_zu using partner
> WHERE partner_zu.pa_id = partner.id
> ...
> The point is the 'using ...'
You can also just set the add_missing_from to true for that one session if you
prefer. I don't think there's any plans to remo
"David Clarke" <[EMAIL PROTECTED]> writes:
> is it really that big an issue these days to have a 100 character primary
> key? Are there postgres-specific implications for either approach?
It's exactly the same size issue as ever. A 20% increase in space usage is a
20% performance hit in certain
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Miroslav ?ulc wrote:
> > Well, "key" is not primary key from another table. It is just a column
> > in pair "key" => "value".
> > The structure of the table is this:
> >
> > Id (primary key)
> > MRTPContactId (id of contact from table MRTPContact)
> >
"Aaron Bono" <[EMAIL PROTECTED]> writes:
> I haven't stared at your query as long as you have so I may have missed
> something
Likewise I'm perhaps speaking too quickly, but at the risk of making a fool of
myself: you should perhaps realize that UNION has to do a fair amount of work
to eliminate
On Sat, Jun 13, 2009 at 12:12 AM, Erik Jones wrote:
>
> On Jun 9, 2009, at 10:51 AM, Rob Sargent wrote:
>
>> Caching helps a *lot* and I'm thankful for that but I would like to take
>> it out of the picture as I massage my queries for better performance.
>> Naturally the first invocation of the qu
On Thu, Jul 2, 2009 at 3:48 PM, Jasmin
Dizdarevic wrote:
> customer ; seg
> 111 ; L1
> 111 ; L2
> 111 ; L1
> 222 ; L3
> 222 ; L3
> 222 ; L2
>
> the result should look like this:
>
> 111: L1 - because L1 is higher than L2 and ratio of L1 : L2 is 2 : 1
> 222: L3 - because L3 is higher than L2 and rat
On Tue, Jul 7, 2009 at 10:17 AM, Simon Riggs wrote:
>
>
> Integer works best since it converts easily to boolean
>
> mybool smallint check (mybool in (0, 1))
>
> You can use "char" also, but the syntax is less clear.
Hm, I was going to suggest using boolean in postgres and making a
"boolean" domai
On Tue, Jul 7, 2009 at 11:33 PM, wrote:
> After some investigation it seems that the new server is refusing to use the
> index's but if I
> limit the number of arguments in the latter part of the statement to 100 then
> it works as
> expected in the expected amount of time using the indexs.
Ugh
On Wed, Aug 12, 2009 at 7:52 PM, Thomas Kellerer wrote:
> Ray Stell wrote on 12.08.2009 20:19:
> I would probably do it this way:
>
> SELECT tt. *
> FROM testtable tt
> WHERE create_date = (SELECT MAX(create_date)
> FROM testtable tt2
> WHERE tt.id = tt2.id);
On Tue, Sep 1, 2009 at 11:31 PM, Rob Sargent wrote:
> How many ways might one accidentally do that I wonder.
Well most operating system distributions ask you when you install them
what region you're in and use a collation for that region.
In 8.4 you can check what collation a database is set to u
SELECT col FROM tab ORDER BY col DESC OFFSET 1 LIMIT 1
In 8.4 OLAP window functions provide more standard and flexibility
method but in this case it wouldn't perform as well:
postgres=# select i from (select i, rank() over (order by i desc) as r
from i) as x where r = 2;
i
99
(1 row)
post
The immutable property had nothing to do with caching results. Postgres
never caches the results of functions. The immutable property is used top
determine if it's safe to use indexes or other plans that avoid evaluating
an expression repeatedly.
On 6 Mar 2010 02:45, "Petru Ghita" wrote:
-BE
On Thu, Mar 25, 2010 at 2:35 PM, Tom Lane wrote:
> When you're intending to have a SQL function be inlined, it's probably
> best not to mark it as either IMMUTABLE or STRICT --- that doesn't buy
> anything and it can complicate matters as to whether inlining is legal.
I'm confused, I thought it w
Huh, I didn't realize that ever worked in the past. I thought the way
to do what the op describes was to cast it to text[] or whatever
datatype you from out-of-band knowledge to expect.
--
Greg
On 13 Dec 2008, at 19:38, Tom Lane wrote:
Corey Horton writes:
I'm trying to use array_to_st
101 - 116 of 116 matches
Mail list logo