rball.
> Frankly, I'd suggest dropping the splits. Thoughts?
I also found the split sources + a non-split sources version to be
confusing. As you, I think that splitting should be dropped.
--
Greetings from Troels Arvin, Copenhagen, Denmark
---(end of broadcast)---
is
- solely - or part of - a uniqueness constraint
- solely - or part of - a foreign key (pointing where?)
- if it is subject to a (set of) CHECK constraints
I could use this to more easily build user interfaces (forms).
--
Greetings from Troels Arvin, Copenhagen, Denmark
---
CREATE TYPE bigobj (INPUT = lo_filein, OUTPUT = lo_fileout,...)
Reference 1:
Stonebraker & Olson: Large Object Support in POSTGRES (1993)
http://epoch.cs.berkeley.edu:8000/postgres/papers/S2K-93-30.pdf
--
Greetings from Troels Arvin, Copenhagen, Denmark
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
IO-wise to "jump" around in an index than to go back
and forth between index and tuple blocks?
--
Greetings from Troels Arvin, Copenhagen, Denmark
---(end of broadcast)---
TIP 8: explain analyze is your friend
ointers in
the index?
Am I right that the answer is related to BlockIdData? If I store
BlockIds in an index, do I then have to worry about physical blocks on
the disk which might somehow move?
--
Greetings from Troels Arvin, Copenhagen, Denmark
---(end of broadcast)--
ams (or
> modify them to 4,5,6 or 7-grams ;) to get some feel how that works.
>
> trigram module is in contrib/pg_trgm.
(/me Printing readme.) Thanks.
--
Greetings from Troels Arvin, Copenhagen, Denmark
---(end of broadcast)---
ies), as opposed to very long, contiguous sequences. Am
I mistaken?
--
Greetings from Troels Arvin, Copenhagen, Denmark
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEma
ng a large index covering all the indexes values
in the column. Is it conceivable to create such an
index "cluster"?
2. Does someone know of interesting documentation (perhaps
in the form of interesting code comments) which I should
read, as a basis for creating a non-standard
n: It's still safe to
call a function including now() NOT DETERMINISTIC==VOLATILE; no unexpected
results should result from this, except - potentially - lower performance.
I think it's a common phenomenon that performance can sometimes be
increased by utilizing certain pr
the same thing.
I'm having a hard time seeing the difference between DETERMINISTIC and
IMMUTABLE.
My suggestion for "NOT DETERMINISTIC"==VOLATILE is because VOLATILE seems
to be the least strict of the three PostgreSQL volatility categories.
Do you disagree on both, or just the
x27;d rather spend my time finishing the
conformance review.
--
Greetings from Troels Arvin, Copenhagen, Denmark
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
ence 1:
An interesting one is this one:
http://article.gmane.org/gmane.comp.db.postgresql.devel.general/10958/match=char+padding
--
Greetings from Troels Arvin, Copenhagen, Denmark
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
e like? I see
no justification for the change: It may break old queries in subtle ways
and doesn't make the CHAR-type any more consistent than before.
--
Greetings from Troels Arvin, Copenhagen, Denmark
---(end of broadcast)---
TIP 1: subs
13 matches
Mail list logo