David Jarvis wrote:
> [...]
>> invest too much time to have the user wait not 4.4, but
>> 2.2 seconds. You could also do the concatenation in the ap-
>> plication if that is faster than PostgreSQL's date arithme-
>> tics.
> No, I cannot. The concatenation uses the year that the measurement was
>
David Jarvis wrote:
>> Have you tested DATE_TRUNC()?
> Not really; it returns a full timestamp and I would still have to
> concatenate strings. My goal is to speed up the following code (where
> *p_*parameters are user inputs):
> *date(extract(YEAR FROM m.taken)||''-'||p_month1||'-'||p_
David Jarvis wrote:
> [...]
> Yes. Here are the variations I have benchmarked (times are best of three):
> Variation #0
> -no date field-
> Explain: http://explain.depesz.com/s/Y9R
> Time: 2.2s
> Variation #1
> date('1960-1-1')
> Explain: http://explain.depesz.com/s/DW2
> Time: 2.6s
> Variatio
Daniel Migowski wrote:
> I have a very common example which would illustrate the
> above problem a bit more. Guess the following view on a
> company table, which references the country of that company
> in another table. The view itself just returns the
> company-id and the country-name,
>cr
Hi,
I have been playing around with PostgreSQL's XML support
lately (cf.
news:m3ljmocolf@passepartout.tim-landscheidt.de>)
and stumbled upon some performance issues related to
XMLPARSE(). In my "application", the XML document is supp-
lied as a string constant via a DBI ? parameter, for testin
