On Sat, 2005-01-01 at 17:47, Simon Riggs wrote:
On Sat, 2005-01-01 at 17:01, Bruce Momjian wrote:
Simon Riggs wrote:
Well, I think we're saying: its not in 8.0 now, and we take our time to
consider patches for 8.1 and accept the situation that the parameter
names/meaning
On Sat, 2005-01-01 at 18:55, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I think the proposal sounds safe, though I worry about performance.
There is no performance loss; we are just changing the order in which
we acquire two locks. If there were some risk of blocking
On Mon, 2005-01-03 at 17:14, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The situation where another backend requests the block immediately
before the I/O is fairly common AFAICS, especially since
StrategyGetBuffer ignores the BM_DIRTY flag in selecting victims.
How do you
on the patch. Is it:
* too late for 8.0
* not the right improvement
* to be applied with doc/default additions
Comments?
---
Simon Riggs wrote:
On Sat, 2005-01-01 at 17:47, Simon Riggs wrote
On Mon, 2005-01-03 at 23:03, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-01-03 at 20:09, Bruce Momjian wrote:
OK, we have a submitted patch that attempts to improve bgwriter by
making bgwriter_percent control what percentage of the buffer is
scanned.
The patch still
On Mon, 2005-01-03 at 19:14 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
Here's my bgwriter instrumentation patch, which gives info that could
allow the bgwriter settings to be tuned.
Uh, what does this do exactly? Add additional logging output?
Produces output like
I guess I could be just unlucky, but I see lots of locks on LWLock 13 in
my trace output for pgbench.
Assuming I count correctly, that is SubtransControlLock.
Why would I be invoking that if I am not issuing a SAVEPOINT ?
Best Regards,
Simon Riggs
---(end
this?
No, but increased security is only possible via increased transparency.
We should explain clearly any such change made in the name of security,
then document it in Developer's FAQ to make sure such problems do not
recur.
--
Best Regards, Simon Riggs
---(end
to
[EMAIL PROTECTED]
Best Regards, Simon Riggs
On Tue, 2005-01-11 at 16:15 -0400, Marc G. Fournier wrote:
Due to several small, and one fairly large, bugs that were found in
Release Candidate 4, we have been forced to release our 5th Release (and
hopefully last) Candidate so that we can get
the reasonably common practice of
using a covered index - i.e. putting additional columns into the index
to satisfy the whole query just from the index.
--
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: the planner will ignore your desire
no direct
account of the workload it is being asked to support, so ISTM that we
should be able to use workload hints, along the lines of
StrategyHintVacuum, to get a more responsive algorithm suited
specifically to PostgreSQL - which would be harder to claim rights on.
--
Best Regards, Simon Riggs
to fund dev of a new buffer management
strategy. If those community members wish to delay release of their own
derived products then that's up to them.
--
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ
,
but it definitely warrants attention in the future.
Agreed.
--
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
On Mon, 2005-01-17 at 15:30 -0800, Joshua D. Drake wrote:
Simon Riggs wrote:
On Mon, 2005-01-17 at 14:02 -0800, Joshua D. Drake wrote:
IBM can NEVER sue customers for using infringing
code before first informing them of infringement and
giving reasonable time to upgrade
On Mon, 2005-01-17 at 18:51 -0500, Andrew Dunstan wrote:
Simon Riggs wrote:
So, it also seems clear that 8.0.x should eventually have a straight
upgrade path to a replacement, assuming the patent is granted.
We should therefore plan to:
1. improve/replace ARC for 8.1
2. backport any
form the basis of a patent.
If such a patch were developed, I don't
think it would be a herculean task to include it in an 8.0.x release
after a lot of careful testing and code review.
Agreed.
--
Best Regards, Simon Riggs
---(end of broadcast
On Thu, 2005-01-20 at 23:17 +1100, Neil Conway wrote:
Simon Riggs wrote:
However, I think the ARC replacement should *not* be a fundamental
change in behavior: the algorithm should still attempt to balance
recency and frequency, to adjust dynamically to changes in workload, to
avoid
per transaction commit would be
worth the potential saving of 10ms on many transactions where group
commit would not gain performance at all. In any case, the functionality
would be optional and turned off by default.
Any comments, please?
--
Best Regards, Simon Riggs
sequential writes.
I'd suggest hardcoding commit_delay at 10ms, but we still need an on/off
switch, so it seems sensible to keep it. We may be in a better position
to use fine grained settings in the future.
--
Best Regards, Simon Riggs
---(end of broadcast
On Mon, 2005-01-24 at 12:12 +0100, Manfred Koizar wrote:
On Fri, 21 Jan 2005 23:52:51 +, Simon Riggs [EMAIL PROTECTED]
wrote:
Currently, we have group commit functionality via GUC parameters
commit_delay
and commit_siblings
And since 7.3 we have ganged WAL writes (c.f. the thread
one I can personally
understand, but we should not close the door on the lock-free algorithm
route just yet, I think.
--
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Wed, 2005-01-26 at 13:30 +1100, Neil Conway wrote:
Simon Riggs wrote:
The one factor which stands out for me from this is that Keir Fraser's
and Tim Harris' algorithms are available as *code*, which additionally
are covered by a licence which appears to be an MIT/BSD variant licence
on a function that was used as part of an AGGREGATE, then
discover that the user could still execute it in the way you suggest.
--
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 8: explain analyze is your friend
Regards, Simon Riggs
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
to search
for the lock to release.
Setting MAX_SIMUL_LWLOCKS to this fairly high number doesn't seem to
match the optimistic use of the O(N) algorithm.
Any thoughts on reducing the size of that array and/or reducing the lock
release time?
Best Regards, Simon Riggs
---(end
From: Neil Conway [mailto:[EMAIL PROTECTED] wrote
Simon Riggs wrote:
Setting MAX_SIMUL_LWLOCKS to this fairly high number doesn't seem to
match the optimistic use of the O(N) algorithm.
...
Perhaps some data on the average value of num_held_locks and
the number
of entries we needed
From: Tom Lane [mailto:[EMAIL PROTECTED] wrote
Simon Riggs [EMAIL PROTECTED] writes:
It looks like padding out LWLock struct would ensure that
each of those
were in separate cache lines?
I've looked at this before and I think it's a nonstarter;
increasing the
size of a spinlock to 128
From: Tom Lane [mailto:[EMAIL PROTECTED] wrote
Simon Riggs [EMAIL PROTECTED] writes:
From: Tom Lane [mailto:[EMAIL PROTECTED] wrote
I've looked at this before and I think it's a nonstarter;
increasing the
size of a spinlock to 128 bytes is just not reasonable.
Well, the performance
approach.
I'd be inclined to move towards that quickly, so we can return to other
issues which can only be addressed when these code changes occur, such
as BufMgrLock contention and bgwriter tuning - neither of which ARC
addresses anyway,
Best Regards, Simon Riggs
---(end
is the eviction of dirty buffers, but more
detail on that in another post. What should be observed there is that
dirty buffer evictions perform Acquire/Release of the BufMgrLock at
least twice. Improving the bgwriter will also have an effect on
BufMgrLock contention.
Best Regards, Simon Riggs
of the free list).
I'm not sure I understand this. Removing clean buffers doesn't cost
much, its the removal of dirty ones that cost, surely? There is no work
to remove a clean buffer.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 1
? That seems to come out much lower than
MemoryContextAllocZeroAligned or MemoryContextAlloc on the profiles I've
seen.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Tom Lane
Simon Riggs [EMAIL PROTECTED] writes:
After much thought, I believe the best way is to implement
bufferpools
(BPs). That is, we don't just have one bufferhash and one
LRU, we have
many pairs. We then work out some mapping by which a block
can be known
to be in a particular BP
.
I think we are describing the exact same issue.
I believe that is a very common case.
Many natural value distributions follow the Zipf distribution, which is
commonly known as the 80-20 curve.
Best Regards, SImon Riggs
---(end of broadcast
for Vacuum.
[I'm assuming that there are no system-wide locks held across I/Os, that
bit seems a bit unclear from the description]
Best Regards, Simon Riggs
On Sun, 2005-02-13 at 17:07 -0500, Tom Lane wrote:
I'm working on an experimental patch to break up the BufMgrLock along
the lines we
certainty about which release their
payback will occur in
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
On Mon, 2005-02-21 at 18:01 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
[I'm assuming that there are no system-wide locks held across I/Os, that
bit seems a bit unclear from the description]
That's always been true and still is, so I didn't dwell on it. Only a
per-buffer
On Mon, 2005-02-21 at 18:45 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
...but do you agree with my comments on the lack of scalability in cache
miss situations?
No. Grabbing a lock during a cache miss is the least of your worries;
you're going to do I/O, or at least
to share theirs?
Just so it is clear, there is not a single criticism on this page from
me; I am merely passing on a pattern that I think I see emerging from a
variety of conversations with clients, course attendees and
press/exhibition contacts.
Many thanks,
Best Regards, Simon Riggs
On Fri, 2005-02-25 at 02:47 -0400, Marc G. Fournier wrote:
On Fri, 25 Feb 2005, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle
On Fri, 2005-02-25 at 00:18 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2005-02-14 at 18:17 -0500, Bruce Momjian wrote:
For development, this means we will _not_ have a shortened, non-initdb
8.1 release but a regular release cycle with the typical big batch of
features
later with more detailed comments on your thoughts so
far.
However, before I spend
too much more time on that, I'd like to get a general response from a
3rd party to let me know if I'm off base.
Third party?
Best Regards, Simon Riggs
---(end of broadcast
on such an issue.
...but, I guess I'll have a stab at it.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
to be that the results of SQL runs without an
ORDER BY would be timing dependant, so would actually be a wholly new
type of test - we would need to run 1 on its own, then compare with 2
run together to check the same answer was still returned, possibly with
a post execution external sort.
Best Regards, Simon
that
interaction cause a switch to a new oprofile output file.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
On Fri, 2005-03-04 at 20:10 -0500, Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Amdahl's Law tells me that looking at the checkpoints is the next best
action for tuning, since they add considerably to the average response
time. Looking at the oprofile for the run as a whole
from the Unisys testing within a few
days.
I had assumed that the majority of the cost of CRC checking was as a
result of the need to log complete blocks, rather than the rather small
xlog records themselves?
Best Regards, Simon Riggs
---(end of broadcast
also.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
.
One might aim to do this in two stages:
1. initially support a single row upsert such as MySQL's REPLACE command
2. a full implementation of MERGE that used set logic as per the spec
...
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 1
On Mon, 2005-03-07 at 20:50 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Well, we're using the CRC in 3 separate places...
(1) for xlog records
(2) for complete blocks copied to xlog
(3) for control files
For (1), records are so short that probably CRC16 would
should be easy to detect in early stages of
optimization.
So, Oleg, for me, the request makes sense, though somebody would need to
code it...
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 2: you can get off all lists at once
Oleg, this idea doesn't seem destine for greatness, so it might be worth
adding that you can avoid the general case problem of incorrectly-
specified-but-long-running query by using statement_timeout...
On Wed, 2005-03-09 at 22:38 +1100, Neil Conway wrote:
Simon Riggs wrote:
Oleg is saying
- is there
still scope to include this for smaller configs?
If not, thanks for taking the time to write the patch and investigate
whether changes in this area would help. Not every performance patch
improves things, but that doesn't mean we shouldn't try...
Best Regards, Simon Riggs
technical reasons which would prevent somebody from
implementing compression?
Not currently, that I'm aware of. But the way additional blocks are
added to xlog records would need to be changed to allow for variable
length output.
It's on my list...
Best Regards, Simon Riggs
be choices along the way that
may need to consider the longer term goal.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 8: explain analyze is your friend
to port their code to
PostgreSQL, in the knowledge that their source code would be secure.
[Dont jump on my case... not everybody thinks open source is cool enough
to actually do it themselves... and I accept their position]
Best Regards, Simon Riggs
---(end of broadcast
if the underlying table changes. That might
need some dependency logic in there...
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
temp_buffers sounds like it
is a global setting, which it would not be.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL
it comes
to it.
Removing FlushRelationBuffers in those circumstances will save a scan of
shared_buffers, but will it save I/O? Perhaps not, but I care more about
the O(N) operation on shared_buffers than I do about the I/O.
Best Regards, Simon Riggs
---(end of broadcast
the allocations.
I guess my vision is for these kind of parameters and much beyond...
shared_buffers = 400
max_fsm_pages = 100
so the O(N) stuff matters... but I realise I'm following Amdahl's Law to
the point where there's nothing significant left to care about.
Best Regards, Simon Riggs
, rather than rely on everything working in the rollforward. That
was true with PITR and similarly true with log shipping based upon PITR.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 8: explain analyze is your friend
a recovery from another
system...
Oh dear. Yes, needs more thought and a bug fix for inclusion in 8.0.2+
is probably warranted.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
On Wed, 2005-03-23 at 13:07 +, Simon Riggs wrote:
On Tue, 2005-03-22 at 19:07 -0500, Tom Lane wrote:
Oleg Bartunov oleg@sai.msu.su writes:
This isn't a problem in normal use of course, but it'd be a serious
issue for someone engaging in WAL-shipping, if their backup postmaster
were
and suffering brain
fade today?
Well, I think the original idea had some validity, but clearly
lazy_update_relstats isn't the way to do it even though we thought so at
the time.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 1: subscribe
On Sun, 2005-03-27 at 23:12 -0500, Jaime Casanova wrote:
On Sat, 19 Mar 2005 11:42:18 +, Simon Riggs [EMAIL PROTECTED] wrote:
I can see that I might want the view to have a different default value
from that of the underlying table. I can see a reason to have multiple
updateable views
transaction changes which is effectively
equivalent to Undo. It is my view that PostgreSQL supports the
equivalent of a full with Redo/with Undo recovery model as a result.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 5: Have you checked
wants to
proceed in that direction, so we may as well remove the last traces.
Agreed.
We still need to explain *why* at some point, but thats still one of my
WIPs.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: the planner will ignore
as it is.
There are no easy answers to this conundrum, but I'm not sure spilling
to disk is the answer.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Thu, 2005-03-31 at 12:24 -0400, Alvaro Herrera wrote:
On Thu, Mar 31, 2005 at 05:07:39PM +0100, Simon Riggs wrote:
On Sun, 2005-03-27 at 16:01 -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
So I think this is dead code. The attached patch removes it.
Yeah
On Mon, 2005-04-04 at 16:27 -0400, Alvaro Herrera wrote:
On Mon, Apr 04, 2005 at 07:08:11PM +0100, Simon Riggs wrote:
IIRC there is not another major system that spills locks to disk and
there's a big reason: performance is very poor. Other systems accept
some limitations in order
such a construct, and might even
conclude that it was very poorly normalised model. I would suggest that
this is much less common in practical use.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send
On Wed, 2005-04-06 at 15:01 +0200, Palle Girgensohn wrote:
I really need to know the *real* arguments...
Why do you need to log the arguments as well?
Thanks,
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: if posting/reading through
On Fri, 2005-04-08 at 00:51 +0200, Palle Girgensohn wrote:
--On torsdag, april 07, 2005 23.31.52 +0100 Simon Riggs
[EMAIL PROTECTED] wrote:
On Wed, 2005-04-06 at 15:01 +0200, Palle Girgensohn wrote:
I really need to know the *real* arguments...
Why do you need to log the arguments
Oliver Jowett [EMAIL PROTECTED] writes:
Simon Riggs wrote:
OK, thats what I hoped you'd say. With a prepared query all of the
statements execute the same plan, so you don't need to know the exact
parameters.
This isn't true in 8.0 if you are using the unnamed statement (as the
JDBC
On Sun, 2005-04-10 at 17:54 +1200, Oliver Jowett wrote:
Simon Riggs wrote:
I've got a patch to submit that logs the EXEC phase, so you get just the
SQL, not the parameters. [...]
Just testing against cvstip and wrapping now...
I assume this replaces the current logging on Parse to avoid
cannot be set
lower than 1 MB.
Could anybody comment on whether the current tests appropriately cover
the correctness of the external sorting algorithms? Will any changes to
the external sort algorithms be appropriately tested by what is there
currently?
Best Regards, Simon Riggs
On Tue, 2005-04-12 at 10:04 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Could anybody comment on whether the current tests appropriately cover
the correctness of the external sorting algorithms?
It's highly unlikely that the regression tests stress external sorts
much
in the
CRC and compression calculations also, an a similar process used to
assist decompression for recovery, in time.
I regret I do not currently have time to pursue further.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 5: Have you checked our
of the effects of highly
variable index value lengths.
Comments?
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Thu, 2005-04-14 at 10:35 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Recent discussions on PERFORM have made me look into some aspects of
B-tree index code, especially with regard to bulk loading high volumes
of data.
Have you read the archived discussions that led
On Thu, 2005-04-14 at 11:15 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The move right only occurs when the page is full, so the chance of
moving right is not 0.99^250, but 0.99, since the previous 249 inserts
would not cause a page split.
Sure, but given that we have
many for my liking, though I do understand the need for
the randomness.
I'd suggest a move right probability of 97% (divide by 16) for itemsz
16 bytes and 94% (divide by 32) when itemsz = 128
Though I think functional indexes are the way to go there.
Best Regards, Simon Riggs
to write
the messages in at shutdown time. (Not happy about that bit, so
suggestions welcome...)
I'd suggest this as a backpatch for 8.0.x, when completed. I'll commit
to doing this in time for 8.1, possibly sooner.
Comments?
Best Regards, Simon Riggs
---(end of broadcast
consider keeping more than one backup set to be
absolutely certain that you are can recover your data.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Mon, 2005-04-18 at 19:21 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The wal file could be truncated after the log switch record, though I'd
want to make sure that didn't cause other problems.
Which it would: that would break WAL file recycling.
Yeh, there's just too
On Mon, 2005-04-18 at 21:25 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The wal file could be truncated after the log switch record, though I'd
want to make sure that didn't cause other problems.
Which it would: that would break WAL file
On Tue, 2005-04-19 at 08:55 +0400, Oleg Bartunov wrote:
On Mon, 18 Apr 2005, Simon Riggs wrote:
but I'm not sure it's best practice to delete them at that point. I
would recommend that users keep at least the last 3 backups. So, I'd
prefer the wording
...all archived WAL segments
be able to do the log switch
as part that.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Wed, 2005-04-20 at 17:18 -0400, Bruce Momjian wrote:
Should any of these be added to TODO?
Yes, please - though some already are.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index
On Mon, 2005-04-25 at 17:10 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2005-04-25 at 11:23 -0400, Tom Lane wrote:
It's not just the scan --- you also have to sort, or something like
that, if you want to count distinct values. I doubt anyone is really
going
command
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
to be
sorted, so you could avoid some Sort steps
for things like GroupAggregates and Merge Joins.
4. No need to VACUUM tables as part of a database-wide VACUUM, which is
particularly important for larger databases.
Best Regards, Simon Riggs
---(end of broadcast
.
Yes, very much agree. Contributions in that area would be most welcome.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Any chance one of you fine people could start another thread?
This has very little to do with Feature freeze date for 8.1...
Thanks,
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
attack) does not necessarily
make sense for a database system.
Security is everybody's job, not just the OS guys. Personally, I forget
that constantly, but the principle seems clear.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3
, with the majority being completed for 8.2. (Bizgres
releases *may* vary from that schedule)
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
, even though I am very
attracted to minimal syntax implementations.
Anyway, that was a bit of a ramble, so thanks for reading this far.
Best regards, Simon Riggs
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister
On Mon, 2005-05-09 at 18:53 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
1. Embellish inheritance or separate infrastructure?
It seems prudent to avoid building on that foundation, even though we
may decide to use some similar approaches.
I disagree. The code
would be that the algorithm's use of the byte-by-byte
calculation together with a bitmask of FF is responsible. Perhaps
varying the length of the bitmask to either 00FF or longer may
help? (see src/include/xlog_internal.h)
Best Regards, Simon Riggs
---(end of broadcast
On Tue, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
On E, 2005-05-09 at 23:30 +0100, Simon Riggs wrote:
ISTM fairly straightforward to produce a similar static plan along the
same lines, using Result nodes to implement Partition Elimination.
Append
Result
SeqScan
Result
501 - 600 of 8408 matches
Mail list logo
