beste Performance Erfahrungen?

wenn ich jetzt so drüber nachdneke klingt das natürlich logisch.
Als ich die Sachen erstellt habe, habe ich an so etwas nicht gedacht.

Ach und mit Zeiteingrenzung macht ers jetzt auch.

ach und noch etwas - was ich gerade in der doku fand:

The following caveats apply to constraint exclusion:

  • Constraint exclusion only works when the query’s WHERE clause contains > constants> . A parameterized query will not be optimized, since the planner cannot know which partitions the parameter value might select at run time. For the same reason, “stable” functions such as CURRENT_DATE must be avoided.

was ich ja irgendwie ein bisserl schade - wenn nicht gar doof - finde … nagut

ich weiss ja nicht, woher deine queries stammen …

Nun, die Zeit kann er nicht verwenden, weil im Index andere Zeiten stehen als du abfragst. Konkret fragst du das Ergebnis einer Funktion ab - woher soll PG wissen, welche Eingabe in die Funktion zu deiner gewünschten Ausgabe passt?

Für so etwas kann man funktionale Indicies nutzen, wie man die erstellt, beschreibt auch die Dokumentation.

Für deine Zeiten musst du entweder TIMESTAMP verwenden oder beim Erstellen des Index eine Zeitzone mit angeben.

der konstante ausdruck mit der zeit in date(…) wird doch sowieso vorher aufgeloest - also der ausdruck - also wird dieser zeitanteil einfach weggekuerzt - weiter unten hat er dann doch noch gezeigt, dass es ja eigentlich geht …

auch so sollte es eigentlich keine rolle spielen was als parameter fuer date() herhalten muss - der rueckgabe-wert / -typ ist doch entscheidend … also im prinzip das muster ::date <= ::date

Es gibt nur auf der rechten Seite einen konstanten Ausdruck, was ist mit dem Ausdruck auf der linken Seite?

Beispiel:

create table symbiont (id serial primary key, zeit timestamp);
create index symbiont_zeit on symbiont(zeit);
set enable_seqscan = off;

Jetzt eine Anfrage, die die Zeit verwendet:

explain select id, zeit from symbiont where zeit < now();
                                  QUERY PLAN
------------------------------------------------------------------------------
 Bitmap Heap Scan on symbiont  (cost=9.27..28.97 rows=647 width=12)
   Recheck Cond: (zeit < now())
   ->  Bitmap Index Scan on symbiont_zeit  (cost=0.00..9.11 rows=647 width=0)
         Index Cond: (zeit < now())
(4 rows)

Sieht soweit gut aus. Nun das gleiche mit date():

explain select id, zeit from symbiont where date(zeit) < date(now());
                                QUERY PLAN
---------------------------------------------------------------------------
 Seq Scan on symbiont  (cost=100000000.00..100000048.80 rows=647 width=12)
   Filter: (date(zeit) < date(now()))
(2 rows)

Ups … war wohl nichts.

Und das ganze noch mal in richtig mit einem funktionalen Index:

create index symbiont_zeit_richtig on symbiont ((date(zeit)));



explain select id, zeit from symbiont where date(zeit) < date(now());
                                      QUERY PLAN
--------------------------------------------------------------------------------------
 Bitmap Heap Scan on symbiont  (cost=9.27..32.21 rows=647 width=12)
   Recheck Cond: (date(zeit) < date(now()))
   ->  Bitmap Index Scan on symbiont_zeit_richtig  (cost=0.00..9.11 rows=647 width=0)
         Index Cond: (date(zeit) < date(now()))
(4 rows)

Schon funktioniert das wie gewünscht.

du hast uebersehen, dass er doch bereits die date() funktion im check constraint verwendet hat … und auch in der query …

daher die verwirrung ueber deinen “hinweis” - der unnötig war

    "filesysdata_200901_fstime_check" CHECK (date(fstime) >= '2009-01-01'::date)
    "filesysdata_200901_fstime_check1" CHECK (date(fstime) <= '2009-01-31'::date)

Select fsfree, fsused, fstime from filesysdata where fsid = 1 and 
                                date(fstime) <= date('2009/07/01 08:00:00') and
                                date(fstime) >= date('2009/07/01 07:00:00') 
                                ORDER BY fstime DESC"

der zeitanteil in der query sollte keine rolle bei der verwendung des index spielen

sicher ist die query und/oder die constraints einfach “falsch” wenn ihm danach war, die zeit zu beruecksichtigen

Nur solange man direkt den Index befragt und nicht über eine Funktion.
Das genau das mit dem vorhandenen Index nicht funktioniert, habe ich zwei Postings vorher gezeigt - und auch die Lösung für das Problem.

Dein Beispiel betrifft doch garnicht das angeblich beschriebene Problem

das hier kommt der sache schon naeher:

explain select id, zeit from symbiont where date(zeit) < date('12-12-1999 12:12:12');



"Bitmap Heap Scan on symbiont  (cost=9.27..28.97 rows=647 width=12)"
"  Recheck Cond: (date(zeit) < '1999-12-12'::date)"
"  ->  Bitmap Index Scan on symbiont_zeit_richtig  (cost=0.00..9.11 rows=647 width=0)"
"        Index Cond: (date(zeit) < '1999-12-12'::date)"

wie ich sagte - der zeitanteil spielt keine rolle - weil er durch date() eh in wohlgefallen aufgeloest wird

oder hier - mit date(now());

explain select id, zeit from symbiont where date(zeit) < date(now());

"Bitmap Heap Scan on symbiont  (cost=9.27..32.21 rows=647 width=12)"
"  Recheck Cond: (date(zeit) < date(now()))"
"  ->  Bitmap Index Scan on symbiont_zeit_richtig  (cost=0.00..9.11 rows=647 width=0)"
"        Index Cond: (date(zeit) < date(now()))"