CREATE INDEX nich auf views?

schade …

weiss jemand warum man das nicht unterstuetzt?

Gegenfrage: wozu sollte man? Ein VIEW ist nix weiter als eine RULE auf eine leere Tabelle.

Andreas

lösen koennen …

ich haette mir ein view gebaut, welches eine textsearch-spalte definiert, dass z.B. alle Felder die meine such-funktion tangieren soll enthaelt.

auf diese eine spalte des views dann den volltext-index … fertsch … ich haette somit den overhead einer aggregierten spalte verhindert, in der nochmal alle daten drinnen stecken …

also ein view in etwa dieser art
SEARCH_VIEW (id, document)

das tolle, ich kann meine anwendung diese eine document spalte durchsuchen lassen, ohne dass ich ruecksicht nehmen muss, ob ich irgendwann spaeter mal ne weitere document spalte hinzu verknuepfe …

… hmm leider wieder ne sackgasse

ist dem wirklich so? das glaub ich doch beinahe nicht … also zumindest sollte es nicht so sein …

Ein View ist bloss Show.

Gleich im ersten Schritt beim Zerlegen des Queries wird anstatt des Views der eigentlich dahinter stehende SQL-Code eingesetzt.


Das würde dein Problem also nicht lösen.



test=# create table ohne_view (i int);
CREATE TABLE
test=*# create table mit_view (i int);
CREATE TABLE
test=*# create rule "_RETURN" as on select to mit_view do instead select * from ohne_view;
CREATE RULE
test=*# insert into ohne_view values (1);
INSERT 0 1
test=*# select * from mit_view;
 i
---
 1
(1 Zeile)


test=*# insert into mit_view values (1);
ERROR:  cannot insert into a view

Andreas

wenn ich einen index auf den view erzeugen koennte, wie es bei jedem guten DBMS geht :slight_smile:

denn dann koennte ich nach dieser show-spalte filtern (waere nur eine) und PG liese sich vielleicht darauf ein den index auf dieser einene spalte auch zu verwenden … da der index-ausdruck genauso aussieht wie der filter-ausdruck - das war der gedanke.

aber geht eben nicht … leider …

Jetzt ohne Dein Problem genau zu kennen - aber ein VIEW basiert auch nur auf Tabellen. Falls Dein VIEW auf eine Funktion von Werten aus diesen Tabellen basiert, nun, PG kennt Indexe, die auf Funktionen basieren.

Andreas

Wie heißen denn die guten DBMS, die einen Index auf eine Select-Anweisung erzeugen?



mfg

fristo

wieso auf eine “Select-Anweisung” … mag sein, dass PG nicht mehr als das kann - aber wenn du auf “Views” wissen willst:

Weltmarktführer-DBMS :slight_smile:

Wenn man jetzt nur wüsste wie ein View definiert ist! Übrigens die englischen Fachbegriffe für “Select-Anweisung” heissen “Query” oder “SELECT STATMENT”. Das Lesen der SYNTAX-Beschreibung von “CREATE VIEW” hätte da auch weiter geholfen.


PG hält sich an den SQL-Standard. Und die wenigen Abweichungen sind in der Doku dokumentiert. So wie das bei anderen Datenbanken auch ist. Wenn Du anderes festgestellt hast, bring doch ganz einfach hier mal den Nachweis, als haltlose Sprüche zu schreiben.


Je nach Standpunkt, Firma und Werbung will jeder der Weltmarktführer-DBMS sein. PG ist es definitiv nicht. Aber warum fällt es Dir so schwer deinen Weltmarktführer-DBMS hier mit Namen zu nennen. Und die Doku, die beschreibt, dass man auf einen View einen Index erzeugen kann, solltest Du auch angeben.



mfg

fristo

das alles ist weder grund genug beleidigt zu sein noch in polemik zu verfallen …

pass auf ich kann das mindestens genauso gut:

du kannst Deine Umwelt noch so sehr mit DEINER korrekten interpretation von “Fachbegriffen” bombardieren, das macht weder Dich, noch PG oder auch Mich “schlauer” bzw. “besser” …

Was ein View sein soll bleibt rein der perspektive ueberlassen. Wenn man innerhalb von PG views eben mit table-funktionalitaet ermoeglicht - warum nicht - das zeugt von entwicklern die abstrahieren konnten. Einen DB-Entwickler, der mit SQL-Kommandos arbeitet interssiert das aber nicht die Bohne - da interessiert nur, was ich mit dem VIEW alles anstellen kann - und da wäre es doch hervorragend, wenn ich mit einem View MOEGLICHST genauso arbeiten kann wie mit einer Table … das hat auch grenzen i.d.R. an technologischen gegebenheiten - ich weiss. Da darfst du gern behaupten ein View sei ein Select-Statement - was Du gern so sehen darfst, aber grundsaetzlich Quatsch ist. Denn das View ist i.A. das Ergebnis eines Select-Statements und das hat in aller Regel die Form einer Tabelle - wie diese “Tabelle” entstanden ist erstmal ist scheiss egal - wenn der View funktioniert.

Und schon siehst du - da hilft das schoene abstrakte konstrukt nix, wenn die Wirklichkeit nach “mehr” verlangt und man dann in Schwulitaeten geraet, dieses “mehr” nicht anbieten zu koennen … nun - ich seh das halb so wild - wenn dieser weg nicht zu einer loesung fuehr, dann eben ein anderer …

Was wollen wir nun? Korrinten kacken? oder doch lieber hier mal da ein bisschen anders sein. Wenn ich mich auf PG einschiesse - und die (mitunter wirklich) tollen vorzuege von PG geniessen moechte, dann ist der “Standard” fuer mich nicht mehr greifbar, da hilft es auch nicht, wenn nur 1 promill der Funktionalitaet am Standard vorbei geht, wenn 99 % der Entwickler zu 100% diese tollen nicht-standard - Funktionen benutzen. Und wenn man schon HIER den Standard “erweitert” da darf mans auch WOANDERs.

MSSQL … MSDN auf den Link verzichte ich … google hilft

Genau. Und warum willst Du auf das fertige Resultat nun einen Index zufügen? Davon abgesehen, das geht sogar. Aber was nützt das Dir?

Andreas

[EDIT] AUWEIA^2

aufgrund deiner Frage (auch wenn ich immernoch nicht weiss, wie man in PG eine index auf einen view erzeugt) habe ich mal folgenden Gedanken verfolgt:

die table:

CREATE TABLE test
(
  id serial NOT NULL,
  t1 text,
  t2 text,
  t3 text
)

ein view auf diese table

CREATE OR REPLACE VIEW vtest AS 
 SELECT (((COALESCE(test.t1, ''::text) || ' '::text) || COALESCE(test.t2, ''::text)) || ' '::text) || COALESCE(test.t3, ''::text) AS stext
   FROM test;

ein textsearch - index auf die obige table

CREATE INDEX ftx_test_idx
  ON test
  USING gin
  (to_tsvector('german'::regconfig, (((COALESCE(t1, ''::text) || ' '::text) || COALESCE(t2, ''::text)) || ' '::text) || COALESCE(t3, ''::text)));

eine die brachiale SEIN ODER NICHT SEIN - abfrage:

explain analyse
select * from vtest 
where to_tsvector('german', stext) @@ 'bla'::tsquery

Juhu :slight_smile:

“Index Scan using ftx_test_idx on test (cost=0.01…8.29 rows=1 width=96) (actual time=0.018…0.018 rows=0 loops=1)”
" Index Cond: (to_tsvector(‘german’::regconfig, ((((COALESCE(t1, ‘’::text) || ’ ‘::text) || COALESCE(t2, ‘’::text)) || ’ ‘::text) || COALESCE(t3, ‘’::text))) @@ ‘’‘bla’’’::tsquery)"

nur falls es irgendjemanden interessiert …

aber wie geht das nun mit dem index auf nen view?

das haengt mit einem problem zusammen, dass ich in einem anderen thread beschrieben habe … und zwar geht es um textsearch funktionalitaet … da muss man ja einen ts_vector aufbauen - denn man dann “dokument” nennt. der kann (und so benoetige ich den) aus mehren feldern durch eine expression erzeugt werden.

diesen vektor wollte ich dann indizieren - nur damit postgres in den spaeteren abfragen den index auch verwendet, muss man genau die gleiche expression auch in der such-abfrage verwenden - sonst lahmts - und die kann ziemlich gräßlich sein wenn man viele felder indizieren will - ich mags eben huebscher.

lt. doku wuerde man fuer diesen fall eine textsearch dokument-spalte einfuehre, die den inhalt aller felder enthaelt. das ist schoen und gut - ich wollte aber den overhead (dass die tabelle nochmal alle daten aus den anderen spalten enthaelt) verhindern.

so war meine idee dazu, dass ich einen view bauen koennte - mit diesem views “einziger” spalte (id wäre auch dabei) - und auf diesen dann einen einfachen textsearch index erzeuge …

so wills aber nicht … ist aber auch egal … ich hab jetzt diese redundante spalte eingefuehrt - arschlecken :slight_smile:

gruss …

Trick 17. Create table as select * from view. Dann create index. Natürlich müßte man das immer wieder neu tun. Der Nutzen dürfte allenfalls marginal sein.

so war meine idee dazu, dass ich einen view bauen koennte - mit diesem views “einziger” spalte (id wäre auch dabei) - und auf diesen dann einen einfachen textsearch index erzeuge …

Dann erzeuge doch einen Index, wie Du ihn brauchst. Auf der Quelltabelle. PG kann funktionale Indexe.

test=# create table s (s1 text, s2 text);
CREATE TABLE
Zeit: 6,808 ms
test=*# create index idx_s on s((coalesce(s1,'') || coalesce(s2,'')));
CREATE INDEX
Zeit: 42,604 ms
test=*# \d s
    Tabelle »public.s«
 Spalte | Typ  | Attribute
--------+------+-----------
 s1     | text |
 s2     | text |
Indexe:
    »idx_s« btree ((COALESCE(s1, ''::text) || COALESCE(s2, ''::text)))

test=*# create view view_s as select coalesce(s1,'') || coalesce(s2,'') as alles from s;
CREATE VIEW
Zeit: 1,199 ms
test=*# explain select * from view_s where alles = 'foo';
                                       QUERY PLAN
----------------------------------------------------------------------------------------
 Bitmap Heap Scan on s  (cost=4.28..12.76 rows=4 width=64)
   Recheck Cond: ((COALESCE(s1, ''::text) || COALESCE(s2, ''::text)) = 'foo'::text)
   ->  Bitmap Index Scan on idx_s  (cost=0.00..4.28 rows=4 width=0)
         Index Cond: ((COALESCE(s1, ''::text) || COALESCE(s2, ''::text)) = 'foo'::text)
(4 Zeilen)

Andreas

weiss ich … das problem ist nur, dass ich dann den index-ausdruck auch in meiner query verwenden muss - damit der index benutzt wird …

mein ziel war es die volltextsuche in EIN “volltext-feld” laufen zu lassen, das aber viruell ist also nicht existiert …

dafuer hab ich aber nun auch eine loesung … wie du in dem edit zu meinem vorherigen antwort lesen kannst … da pg gluecklicherweise das select auf die concatenierte spalte des view mit der expressen des concatenierten index der ursprungstabelle aufloest, wird auch dieser index verwendet …

danke trotzdem

Dann musst du auch EIN Feld bereitstellen und nicht zwei Felder und dann erwarten, das viel Magie das ganze doch zum Funktionieren bringt.

Langsam wir die Diskussion müßig mit dir …

sei nicht so schlau! :smiley:

ich kann ja auch bei normalen indizes eine reihe von feldern angeben die in den index aufgenommen werden, dann aber nur z.B. das 1. aufgezaehlte feld in der query nutzen und dieser zusammengesetzte index wird trotzdem von PG berücksichtig!

daher mein frommer wunsch, dass eine ts query auf ein “beliebiges” feld in einem ts index - ausdruck auch dazu fuehren wuerde, den ts index zu nutzen. freilich kann ein index ausdruck auch komplexer sein - aber ich hoffte, dass zumindest bei einem schnoeden concatenieren von feldern pg trotzdem diesen index nutzt, auch wenn ich nur ein einziges derer felder in der ts-query verwende … funktionierte aber leider nicht so …

daraufhin hab ich mir eben ueberlegt wie ich pg dazu bringen koennte, komplexe ts-indexe zu verwenden, ohne in meiner query den gesamten index-schmarn auffuehren zu muessen … das hab ich inzwischen selbst erörtert - kannst im thread ein paar ebenen hoeher unter [EDIT] nachschauen …

grüßerz

p.s. mehr interesse bitte - dann koennt auch ihr nochwas lernen