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
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
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
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
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
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
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
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)---
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)--
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
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
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
---
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)---
13 matches
Mail list logo