Bruno wrote:
>
> Can you document which part of a mixed interval (with both months and
> seconds parts) gets added first to a timestamp? I haven't ever run
> across anything which says which gets done first.
>
In the existing code, the sql spec, or the proposed implementation?
In the existing c
Tom wrote:
> At this point it should move to pghackers, I think.
(responding to a patch for ISO 8601 "Time Intervals" in pgsql-patches)
Looks like I'll take a shot at more broadly hacking the postgresql
time interval code. Before doing so, I wanted to ask opinions
regarding what the "right" beh
Tom wrote...
> At this point it should move to pghackers, I think.
Background for pghackers first, open issues below...
Over on pgpatches we've been discussing ISO syntax for
time intervals of the format with time-unit designators.
http://archives.postgresql.org/pgsql-patches/2003-0
Tom wrote:
> > Do we have any "killer" features added to 7.4 that we can shout about?
>
> We have a lot of pretty good stuff. You're not happy that the
> performance of IN (subselect) has been fixed? That btree index bloat is
> fixed...
For warehousing & reporting, "Add hash for evaluating GROU
Jeroen T. Vermeulen wrote:
>
>After that, where do you go? Try to find a reasonable process to shoot
>in the head. From what I heard, although I haven't kept current, a lot
>of work went into selecting a "reasonable" process, so there will be some
>determinism.
FWIW, you can browse the logic li
Tom wrote:
>
>I find it really really hard to believe that it's wise to run with
>sort_mem exceeding 2 gig ;-). Does that installation have so much
>RAM that it can afford to run multiple many-Gb sorts concurrently?
I don't do 2 gig... but I found 0.3 gig helped on a not-too-large system.
In a
mlw wrote:
> ...
>select * from table where field = 'blah';
>gave the same results as:
>select * from table where field = 'BLah';
>
>I was shocked. (a) because I know a lot of my code could be easier to
>write
> ...
select * from table where field ILIKE 'blAH'; -- ;-)
is almost as easy :-)
PS
Christopher Kings-Lynne wrote:
>
>*sigh* It's just like a standard to come up with a totally new syntax for a
>feature that no-one has except MySQL who use a different syntax :)
You sure? :)
http://otn.oracle.com/products/oracle9i/daily/Aug24.html
MERGE INTO SALES_FACT D
USING SALES_JUL
FWIW, that's the approach O*'s taking.
http://otn.oracle.com/products/oracle9i/daily/Aug24.html
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Peter Eisentraut
Sent: Tuesday, February 18, 2003 11:02 AM
To: Christopher Kings-Lynne
Cc: Tom Lane; Hackers
Su
Christopher Kings-Lynne wrote:
>
>I reckon that sort_mem is the hardest thing to optimise1
>
Agreed... in part because it depends a lot on the query.
Also, if I understand correctly sort_mem not only affects sorts
but also hash table stuff as well, right? If that's true for
the new hash aggrega
On Thu, 30 Jan 2003, Dave Page wrote:
> > On Wed, 29 Jan 2003, Ron Mayer wrote:
> > >
> > > Cool irony in the automated .sig on the mailinglist software...
> > > [...]
> > > Sounds like you're basically saying is
> > >_do_ 'kill -9&
Cool irony in the automated .sig on the mailinglist software...
On Wed, 29 Jan 2003, Vince Vielhaber wrote:
> ...
> hammering the betas is a far cry from an "industrial-strength solution".
> ...
> TIP 4: Don't 'kill -9' the postmaster
Sounds like you're basically saying is
_do_ 'kill -9' t
301 - 312 of 312 matches
Mail list logo
