On Fri, 23 Jun 2006, Jonah H. Harris wrote:
On 6/23/06, Mark Woodward [EMAIL PROTECTED] wrote:
Rather than keep references to all versions of all
rows in indexes, keep only a reference to the first or key row of each
row, and have the first version of a row form the head of a linked list to
On Sat, 24 Jun 2006, Mark Woodward wrote:
I'm probably mistaken, but aren't there already forward references in
tuples to later versions? If so, I'm only sugesting reversing the order
and referencing the latest version.
I thought I understood your idea, but now you lost me again. I thought
On Sat, 24 Jun 2006, Bruce Momjian wrote:
OK, I have an idea. Right now, an UPDATE where the old and new rows are
on the same page have two index entries. What if we made only one index
entry for both? We already have UPDATE chaining, where the old row
points to the new one. If no key
On Sat, 24 Jun 2006, Bruce Momjian wrote:
Because having them be on the same page is the only way you can update
the page item pointer so when you recycle the row, you the indexes are
now pointing to the new version. Pages look like:
On Mon, 26 Jun 2006, Jan Wieck wrote:
On 6/25/2006 10:12 PM, Bruce Momjian wrote:
When you are using the update chaining, you can't mark that index row as
dead because it actually points to more than one row on the page, some
are non-visible, some are visible.
Back up the truck ... you mean
On Mon, 24 Jul 2006, Tom Lane wrote:
Personally I don't think retail vacuuming in that form will ever fly
anyway, so I have no problem with installing the proposed patch,
but I thought I'd better throw this comment out to see if anyone
thinks it's a big deal.
My feeling is that retail
Bruce Momjian wrote:
I am keeping URLs in the TODO list. Why don't people submit
improvements to the TODO list, rather than adding more complexity by
making a separate wiki for every TODO item? If no one updates the TODO
item, what makes you think they are going to do somethin in a wiki?
Gene wrote:
You are correct the main part I'm worried about is the updates, being
so far from the originals.
Yeah, you won't benefit from the patch at all.
The reason I'm doing the clustering is I was hoping that with the
stable non-updating partitions I could execute a CLUSTER at night
Jonah H. Harris wrote:
On 8/9/06, Tom Lane [EMAIL PROTECTED] wrote:
UPDATE tries to place the new tuple on the same page it's already
on.
I think he meant for INSERT.
Right. Update is indeed taken care of already.
One example where this would help would be a customer_history table that
anyways...]
Actually, we already have our own qsort implementation in
src/port/qsort.c for those cases.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
release. Jie and/or Gavin, could you send the
latest version of the patch to the list in any case? Do you want help
with the patch, or would I be stepping on your toes?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
Gregory Stark wrote:
But why would you use UTF8 to encode fixed length ascii strings?
The encoding is set per-database. Even if you need UTF-8 to encode
user-supplied strings, there can still be many small ASCII fields in the
database. Country code, currency code etc.
--
Heikki Linnakangas
case-by-case. Of course, usually you have a default
set per-database, per-table or per-column, but it's not a property of
the actual value of a field. I think that the phrase collation of a
string doesn't make sense.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
and lc_ctype
settings?)
Sure. Don't do that, that's just silly. But I don't see how that's relevant.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
database relations
through,other than rotines in bufmgr.c nd freelist.c(I mean any other
routines like ReadBuffer,StrategyGet etc.)
No.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget
scanning of relation by editing the functions ReadBuffer()
and BufferAlloc(),StrategyGetBuffer().
That sounds valid.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet
think you need to define
indexes on a2 and b2, if you don't have them already, and coerce the
planner to choose a nested loop join. I'd suggest using SET
enable_seqscan=false; SET enable_bitmapscan=false; and see if that gets
you a nested loop join.
--
Heikki Linnakangas
EnterpriseDB http
Praveen Kumar N wrote:
On Fri, 8 Sep 2006, Heikki Linnakangas wrote:
Looks like Alvaro guessed right. It reads both relations in sequence,
sorts them in temporary storage, outside bufmgr, and then does a
merge join on the sorted inputs.
could you tell me how can we trace that? I mean which
for the
key, and try to create one, one backend will get a duplicate key error
on the lov index.
Also, vacuum actually does a reindex, which seems awfully wasteful. That
needs to be looked at.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end
and gin. The new bitmap index code uses them, but
only as an internal boolean flag indicating that the scan has been
initialized, so that should be fixed anyway.
How about removing those fields from IndexScanDesc?
There's also is_multiscan field which is set but never read.
--
Heikki
bits of the first byte. So we could
store a UTF-8 encoded CHAR(1) field without any additional length header.
See http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8 for the bit patterns.
AFAIK, UTF-16 works similarly.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Martijn van Oosterhout wrote:
On Fri, Sep 15, 2006 at 10:01:19AM +0100, Heikki Linnakangas wrote:
Actually, you can determine the length of a UTF-8 encoded character by
looking at the most significant bits of the first byte. So we could
store a UTF-8 encoded CHAR(1) field without any additional
going to store codes like 'A', 'B', 'C' or
'1', '2', '3' in it, and you don't need UTF-8 for that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
pointer
The decoding algorithm is similar to Tom's proposal, and relies on using
0x00 for padding.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives
for bitmap indexes is large data warehouses where you don't do
concurrent updates, but still...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
in the system as we do now.
Comments?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
/ReleaseBuffer (etc.) calls.
It's implemented in src/backend/storage/buffer/bufmgr.c
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
memory. I don't remember how it's sized.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'm thinking of removing cmin and cmax, and keeping that information in
backend-private memory instead.
I don't believe you can remove *both*. What's been discussed is
removing one of them, by letting the field represent
fine with the right data structure.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
to remove one.
It would be a win on 32-bit architectures. And there has been discussion of
storing at least some data types unaligned.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget
Simon Riggs wrote:
+
+ if (startupAfterRecovery)
+ ereport(ERROR,
+ (errmsg(recovery ends normally with startup_after_recovery=false)));
+
I find this part of the patch a bit ugly. Isn't there a better way to
exit than throwing an error that's not really an error?
--
Heikki Linnakangas
(cmax) + sizeof(phantomcid) + sizeof(HASHELEMENT) = 20
Total: 28 bytes (or 32 if MAXALIGN is 8-bytes)
this excludes overhead of hash table buckets etc.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
A big question is, do we need to implement spilling to disk?
My thought is no, at least not in the first cut ... this is something
that can be added later if it proves critical, and right at the moment
my guess
and cmax system columns to avoid confusion, and replace
them with cminmax, that returns what's on disk.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
there
is, though.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
already
support for lossy bitmap pages. Doing normal ordered index scans
requires some coding, but can be done.
Thoughts? I'm thinking of getting this in early in the 8.3 cycle. We'll
have to take a look at the indexam API to support both bitmap indexes
and block B-trees nicely.
--
Heikki
What's the purpose of mark/restrpos in heapam.c?
AFAIK, mark/restore is only used by merge joins, and you can't feed a
merge join from a heap scan because merge join requires sorted input.
Unless I'm missing something, heap_markpos and heap_restrpos are dead code.
--
Heikki Linnakangas
the
LP_DELETE flag either. We might want to do something about that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I've been experimenting with the idea of a so-called Block B-Tree. The
basic idea is that instead of storing an index tuple for each heap
tuple, we store an index tuple for each heap block. This dramatically
reduces the size
in StreamBitmap that's called by the consumer of the bitmap
after it's done with it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Another question is, what should cmin and cmax system columns return?
If we're going to fool with these, I'd like to renew the suggestion I
made awhile back that none of the system columns should have explicit
entries
and no additional
vacuum is really needed.
Also, now that we have concurrent CREATE INDEX, we could implement
concurrent REINDEX as well, I believe.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9
Heikki Linnakangas wrote:
Tom Lane wrote:
Anything that involves having VACUUM re-evaluate index expressions is a
nonstarter ... or have you already forgotten the optimizations we put
into 8.2 that assume, eg, no sub-transactions within a VACUUM?
Umm, I'm afraid I have. Could you give me
involves
re-evaluating index expressions.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
. And we might as well just
disable the optimization that's causing us problems.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe
.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Jim C. Nasby wrote:
Granted, you'd want to periodically ensure that you scan the entire
index, but that shouldn't be horribly hard to set up.
Well, it seems to be. A vacuum can't evaluate index expressions because
it's not in a real transaction
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
AFAICS, we could disable the optimization and use a full-blown
transaction when vacuuming a table with a functional block index.
No, we couldn't, or at least it's not merely a matter of reversing a
recent optimization
? You can't just strip out cid info when
writing to disk, if you don't want to lose the information.
And it's certainly a lot more complicated than the phantom id thing.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get
Heikki Linnakangas wrote:
If we want to keep the property that VACUUM doesn't re-evaluate index
entries, any proposal that doesn't keep track of every heap tuple
isn't going to work. I'll try to modify the design I had in mind so
that it does keep track of every heap tuple in some form.
After
Martijn van Oosterhout wrote:
On Fri, Sep 29, 2006 at 09:35:31AM +0100, Heikki Linnakangas wrote:
We could get rid of t_hoff, because we should always be able to
calculate the header size. Then we're down to 18 bytes.
Without t_hoff, how do you know the size of the null bitmap? You could
Martijn van Oosterhout wrote:
On Fri, Sep 29, 2006 at 10:59:13AM +0100, Heikki Linnakangas wrote:
Martijn van Oosterhout wrote:
On Fri, Sep 29, 2006 at 09:35:31AM +0100, Heikki Linnakangas wrote:
We could get rid of t_hoff, because we should always be able to
calculate the header size
Martijn van Oosterhout wrote:
On Fri, Sep 29, 2006 at 10:51:32AM +0100, Heikki Linnakangas wrote:
After some thought:
Imagine a normal B-tree just like what we have now. But when there is
more than one tuple on the same heap page with consecutive index keys,
we represent all of them
Simon Riggs wrote:
On Fri, 2006-09-29 at 10:51 +0100, Heikki Linnakangas wrote:
Heikki Linnakangas wrote:
If we want to keep the property that VACUUM doesn't re-evaluate index
entries, any proposal that doesn't keep track of every heap tuple
isn't going to work. I'll try to modify the design I
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'm not very interested in the case where you have a lot of equal keys,
I think the bitmap index am is more suitable for that.
that indeed you meant to write consecutive, and I've got a problem
with that: define consecutive
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I don't mean consecutive as in 1, 2, 3, 4, ... without gaps but as in
A and B are consecutive in the index, if there's no value X in the
index so that A X B. Maybe there's a better word for that.
Um, but how are you going
to single heap tuples.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
scan of the table, which is
slower than a seqscan + sort if the table is not already clustered.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives
. I've CC'd the pgsql-hackers list.
Could you capture the failing SQL query, please? If you could send it to
the list, it would help us to diagnose the problem. Also, could you try
to run it in psql and see if it crashes then as well?
--
Heikki Linnakangas
EnterpriseDB http
be.
3. planner/stats changes, so that the planner can estimate how much of
an index scan can be satisfied without looking at the heap (it's not an
all-or-nothing plan-time decision with this design)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers
would choose the best
plan for a bloated table like that (it probably does, I'm not sure) as well.
However, I'm not sure how much we can trust the statistics for a table
we're about to CLUSTER. Often you run CLUSTER on a table you've just
loaded or mass-updated.
--
Heikki Linnakangas
Tom Lane wrote:
Does anyone think this might be too chatty?
No.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
David Fetter wrote:
On Mon, Sep 01, 2008 at 09:00:47PM +0300, Heikki Linnakangas wrote:
Ok, I'm starting to read up on SQL2003 window functions,
Maybe it would be better to read the SQL2008 standard
http://wiscorp.com/sql200n.zip :)
Ah, thanks!
--
Heikki Linnakangas
EnterpriseDB http
Gregory Stark wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
sfunc is called once for each input row. Unlike with normal aggregates, sfunc
is passed the whole input row, so that e.g RANK can compare it against the
previous row, or LEAD can buffer it.
I'm not sure I follow this bit about
to find out sooner rather
than later when recovery is needed.
So IMHO, just use shared_preload_libraries.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
error yesterday, but I was building in-tree. make
maintainer-clean worked for me.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Hitoshi Harada wrote:
2008/9/2 Heikki Linnakangas [EMAIL PROTECTED]:
In my understanding, the Window Frame is defined
by clauses such like ROWS BETWEEN ... , RANGE BETWEEN ... or so,
contrast to Window Partition defined by PARTITION BY clause. A
frame slides within a partition or there's only
missing functionality later on.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
for collecting footprints from build farm members.
Ok, understood. I'll take another look from that point of view.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Simon Riggs wrote:
On Tue, 2008-09-02 at 15:51 +0300, Heikki Linnakangas wrote:
The needs of access to the rows are so different that it seems best to
me to delegate the buffering to the window function.
That seems sensible in some ways, not others.
In the API I proposed later in that mail
Hitoshi Harada wrote:
2008/9/2 Heikki Linnakangas [EMAIL PROTECTED]:
Hitoshi Harada wrote:
2008/9/2 Heikki Linnakangas [EMAIL PROTECTED]:
In my understanding, the Window Frame is defined
by clauses such like ROWS BETWEEN ... , RANGE BETWEEN ... or so,
contrast to Window Partition defined
values are, so it's immediately clear what you need to
fix if you get that wrong.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
?
src/include/storage/bufmgr.h
src/include/postmaster/bgwriter.h
Hmm, apparently not.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
like your design docs page, but you're free
to use the Wiki as well, of course.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
Heikki Linnakangas wrote:
I'll review the parser/planner changes from the current patch.
Looks pretty sane to me. Few issues:
Is it always OK to share a window between two separate window function
invocations, if they both happen to have identical OVER clause? It seems
OK for stable
already contains all the useful information.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of this approach is
performance penalty.
Please, let me know your opinion about this approach.
Future work:
1) learn WAL to process different tuple structure version
2) tuple conversion to new version and put it into executor
(ExecStoreTuple)
3) multiversion MaxItemSize constant
--
Heikki Linnakangas
Simon Riggs wrote:
On Thu, 2008-09-04 at 11:07 +0300, Heikki Linnakangas wrote:
Scenario: The binary tree on a page is corrupt, so that the value of an
upper node is Max(leftchild, rightchild).
Consequence: Searchers will notice the corruption while trying to
traverse down that path
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
I'm afraid I still fail to see the usefulness of this. gdb knows how
to deal with structs,
If I correct that GDB knows structure only if you have debug version.
But usually you don't have debug version on production system.
Using gdb
Zdenek Kotala wrote:
OK. You convinced me that information could be collected from other
sources.
Great, I'm glad we're in agreement.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
to paint the .pgpass based password handling
insecure because dblink makes the file world-readable. I still
fail to see how this any way points to flaws of the scheme... ]
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
The patch seems to be missing the new htup.c file.
I'm sorry. I attached new version which is synchronized with current
head. I would like to say more comments as well.
1) The patch contains also changes which was discussed during July
-in-place. There's just the catalog changes, but AFAICS
nothing that would require scanning through relations.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
will the FSM
rewrite. Not sure about DSM yet.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Gregory Stark wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Relation forks didn't change anything inside relation files, so no scanning of
relations is required because of that. Neither will the FSM rewrite. Not sure
about DSM yet.
And just to confirm -- they don't change the name
as well? Most
people probably don't look at the dump files, but if someone needs to
deal with a data-only dumps that contain circular constraints, and also
those that don't, it would be invaluable information.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql
David Rowley wrote:
Thanks for all the reviews and suggestions.
David, could you re-run the performance tests you ran earlier? I'm
curious to know what impact switching to the simpler loop for 1-byte
pattern had.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Relation forks didn't change anything inside relation files, so no
scanning of relations is required because of that. Neither will the
FSM rewrite. Not sure about DSM yet.
Does it mean, that if you inject old data file after catalog upgrade
Simon Riggs wrote:
I think there needs to be an option to force this to do either sorts or
indexscans.
If we use the planner, set enable_indexscan =off or set
enable_sort=off ought to work.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers
Zdenek Kotala wrote:
Tom Lane napsal(a):
Heikki Linnakangas [EMAIL PROTECTED] writes:
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release to
implement upgrade-in-place. There's just the catalog changes
Simon Riggs wrote:
This gives us the Group Commit feature also, even if we are not using
replication. So we can drop the commit_delay stuff.
Huh? How does that give us group commit?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
is, how does A know if it should wait, and for how long?
commit_delay sure isn't ideal, but AFAICS the log shipping proposal
doesn't provide any solution to that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
don't
think its a deal breaker.
Oh, OK, that's obvious --- there's no place to put more data.
Each WAL sender can keep at most one page locked at a time, right? So,
that should never happen if wal_buffers 1 + n_wal_senders.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
, because the master will block before that
happens. Also in asynchronous replication? And what about when the slave
is first set up, and needs to catch up with the master?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Simon Riggs wrote:
On Wed, 2008-09-10 at 13:28 +0900, Fujii Masao wrote:
On Tue, Sep 9, 2008 at 8:38 PM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
There's one thing I haven't figured out in this discussion. Does the write
to the disk happen before or after the write to the slave? Can you
there.
Note that we already have the same problem with encodings. If you create
a database with LATIN1 encoding, load it with data, and then use that as
a template for a database with UTF-8 encoding, the text data will be
incorrectly encoded. We should probably fix that too.
--
Heikki
101 - 200 of 6533 matches
Mail list logo
