Kevin Grittner wrote:
Thomas Zaksek wrote:
Is this query plan near to optimal or are their any serious flaws?
I didn't see any problem with the query, but with the information
provided, we can't really tell if you need to reconfigure something,
or maybe add an index.
Hi,
subject is the following type of query needed in a function to select data:
SELECT ' 13.04.2009 12:00:00 ' AS zeit,
'M' AS ganglinientyp
Scott Marlowe schrieb:
Yeah, it didn't help. I was expecting the query planner to switch to
a more efficient join plan.
Try setting it higher for JUST THIS query. i.e.
set work_mem=128M;
explain analyze select
and see how that runs. Then play with it til you've got it down to
what
For so many rows I'm surprised it's not using a bitmap indexscan.
What PG version is this? How big are these tables?
regards, tom lane
Its PG 8.2.6 on Freebsd.
messungen_v_dat_2007_11_12 ist about 4 million rows and messwerte is
about 10 million rows.
-
We have tried some recoding now, using a materialized view we could
reduce the query to a join over too tables without any functions inside
the query, for example:
explain analyse SELECT '12.11.2007 18:04:00 UTC' AS zeit,
'M' AS ganglinientyp,
zs_de,
> Can you send the table definitions of the tables involved in the
> query, including index information? Might be if we look hard enough we
> can find something.
>
> Peter
Table "messungen_v_dat_2007_11_12"
Column | Type | Modifiers | Description
---+--+-
Scott Marlowe schrieb:
On Feb 11, 2008 12:08 PM, Thomas Zaksek <[EMAIL PROTECTED]> wrote:
I have serious performance problems with the following type of queries:
/
/explain analyse SELECT '12.11.2007 18:04:00 UTC' AS zeit,
'M' AS datatyp,
I have serious performance problems with the following type of queries:
/
/explain analyse SELECT '12.11.2007 18:04:00 UTC' AS zeit,
'M' AS datatyp,
p.zs_nr AS zs_de,
j_ges,
de_mw_abh_j_lkw(mw_abh) AS j_lkw,
