Simon Riggs wrote:
Hmmm. I think it fits rather neatly with BitmapIndexScans. It would be
easy to apply the index condition and/or filters to see which segments
are excluded and then turn off bits in the bitmap appropriately.
Yeah, good point.
Not fully sure about IndexScans yet. I don't
Simon Riggs wrote:
I have to admit I always found it kludgy to have objects named
invoices_2000_JAN and invoices_2000_FEB and so on. It's kind of an meta
denormalization. But so is specifying where clauses repeatedly.
The idea for using the WHERE clauses was to specifically avoid naming.
I
Hi,
Gregory Stark wrote:
That's an interesting thought. I think your caveats are right but with some
more work it might be possible to work it out. For example if a background
process processed the WAL and accumulated an array of possibly-dead tuples to
process in batch. It would wait whenever
Hi,
Simon Riggs wrote:
With that in mind, can I clarify what you're thinking, please?
Sure, I can try to clarify:
2) the things you've been discussing are essential requirements of
partitioning and we could never consider it complete until they are also
included and we must therefore talk
Hi,
Simon Riggs wrote:
When I delete all rows WHERE some_date 'cut-off date' on a segment
boundary value that would delete all segments that met the criteria. The
following VACUUM will then return those segments to be read-write, where
they can then be refilled with new incoming data. The only
Hi,
Gokulakannan Somasundaram wrote:
But i am just thinking of creating the DSM
by reading through the WAL Logs, instead of asking the Inserts, updates
and deletes to do the DSM creation.
What's the advantage of that? What's wrong with collecting the
information for DSM at transaction
Hi,
Simon Riggs wrote:
On Wed, 2008-01-09 at 18:04 +0100, Markus Schiltknecht wrote:
What do you think about letting the database system know the split point
vs it having to find optimal split points automatically?
For me, managing the table's files can be separate from the chunking
Hi,
Gokulakannan Somasundaram wrote:
because of the contention. Am i missing something
here? While Vacuum is reading the DSM, operations may not be able to
update the bits. We need to put the DSM in shared memory, if all the
processes are going to update it, whereas if Vacuum is going to form
Hi,
Gokulakannan Somasundaram wrote:
I'm also not sure it really buys us anything over having a second
dead-space-map data structure. The WAL is much larger and serves other
purposes which would limit what we can do with it.
Ok. One obvious advantage is that it saves the contention
Hi,
Tom Lane wrote:
Well, one of the principal arguments for having VACUUM at all is that it
off-loads required maintenance effort from foreground transaction code
paths.
Off-loading doesn't mean we don't have to do the work, so it's obviously
is a compromise.
AFAICT, having to write some
Hi,
Jeff Cohen wrote:
We did look at allowing general functions for partitioning and this was
one concern. The other is that we want to enforce that a row only gets
inserted into a single partition, so we wanted a declarative syntax
where it was relatively easy to check that range and list
Hi Jeff,
Jeff Cohen wrote:
If you don't define a default partition to handle outliers, the
insert should fail with an error.
IMO, you should always have a default partition, then, so as not to
violate the constraints (by rejecting tuples which are correct according
to the constraints).
Hi,
Hannu Krosing wrote:
I guess it would go to some default partition ?
Which doesn't have a name so far, which prevents from addressing that
partition. Nor is it pretty well defined, it's just a rest.
sure, but this can become really tedious for 1024 partitions,
Well, managing 1024
Hi,
Hans-Juergen Schoenig wrote:
What do you need so many partitions for?
having so many tables is not funny but it can be the only reasonable choice.
Well, what do you do with all those partitions? Most of them will end up
on the same storage subsystem. So, if you don't partition to
Hi,
Tom Lane wrote:
I don't agree with that at all. I can imagine plenty of situations
where a tuple falling outside the range of available partitions *should*
be treated as an error. For instance, consider timestamped observations
--- data in the future is certainly bogus, and data further
Hi,
Gregory Stark wrote:
In a previous life I had a database which had daily partitions. I assure you
it was unquestionably the right decision. Each day's data wasn't just
distinguished by the timestamp but actually was entirely separate from the
previous day's data. Both the archiving strategy
Hi,
Tom Lane wrote:
DBAs tend to be belt *and* suspenders guys, no?
I rather know those admins with stupid looking faces who are wondering
why their transactions fail. Often enough, that can have a lot of
different reasons. Extending the set of possible traps doesn't seem like
a clever
Hi,
Zeugswetter Andreas ADI SD wrote:
Yes, but the problem with the timestamp partitioned tables is, that the
window is sliding. Thus you would need two alter tables for each new
period. One that changes the constraint + one that creates the new
partition. So it seems natural to join the two
Hi,
(sorry for the previous one, if delivered, that went of too early...)
Zeugswetter Andreas ADI SD wrote:
Yes, but the problem with the timestamp partitioned tables is, that the
window is sliding. Thus you would need two alter tables for each new
period. One that changes the constraint + one
Hello Bruce,
Bruce Momjian wrote:
Here is a new replication documentation section I want to add for 8.2:
ftp://momjian.us/pub/postgresql/mypatches/replication
Comments welcomed.
Thank you, that sounds good. It's targeted to production use and
currently available solutions, which
Hannu Krosing wrote:
I think the official term for this kind of replication is
Shared-Nothing Clustering.
Well, that's just another distinction for clusters. Most of the time
it's between Shared-Disk vs. Shared-Nothing. You could also see the very
Big Irons as a Shared-Everything Cluster.
Hello Josh,
Josh Berkus wrote:
Hmmm ... while the primer on different types of replication is fine, I
think what users were really looking for is a listing of the different
replication solutions which are available for PostgreSQL and how to get
them.
Well, let's see what we have:
* Shared
Hi,
Bruce Momjian wrote:
I have updated the text. Please let me know what else I should change.
I am unsure if I should be mentioning commercial PostgreSQL products in
our documentation.
I support your POV and vote for not including any pointers to commercial
extensions in the official
Hi,
Jim C. Nasby wrote:
Those to statements are at odds with each other, at least based on
everyone I've ever talked to in a commercial setting. People will use
terms like 'replication', 'HA' or 'clustering' fairly interchangably.
Usually what these folks want is some kind of high-availability
Hello Bruce,
You wrote:
I am still feeling that data partitioning is like master/slave
replication because you have to get that read-only copy to the other
server.
Yes, that's where replication comes into play. But data partitioning per
se has nothing to do with replication, has it? You
Good morning Hannu,
Hannu Krosing wrote:
People do that in cases where there is high write loads (high as in
not 10+ times less than reads) and just replicating the RO copies
would be prohibitively expensive in either network, cpu or memory terms.
Okay. It that case it's even less like any
Hi,
Peter Eisentraut wrote:
Are there any issues with tsearch2 not in core?
I have run into troubles when restoring a dump, especially across
different versions of PostgreSQL and tsearch2. Mainly because pg_ts_*
are not system tables and thus need to be restored or installed separately.
Hi,
I've just read most of that thread and found it rather disappointing.
I'd just like to add my 2 (or 3) cents:
a) I like to have the freedom to choose what software (under which
licenses) I'm using. Thus I'd like to see GNUTLS supported, as it adds
an additional feature to PostgreSQL per
Hi,
Martijn van Oosterhout wrote:
Please read the OpenSSL-GPL FAQ. They themselves acknowledge it's a
problem, but claim they fall under the operating system exception,
which is fine for everyone except the distributor of the operating
system.
http://www.openssl.org/support/faq.html#LEGAL2
Hi,
[EMAIL PROTECTED] wrote:
Nobody has proven an issue exists. The only way to prove it would be
for an actual court case to set the precident.
That's exactly the mentality that I'm questioning. Why always go to
legal boundaries and ask for courts?
Joshua D. Drake wrote:
Further, OpenSSL
Hi,
I've just run into a race condition with creating a database and
connecting to it immediately afterwards. I'm getting a database %s not
found error just after the first flatfiles check in InitPostgres().
What that FindMyDatabase() there does, besides checking if the database
exists, is
Hello Tom,
Tom Lane wrote:
In what PG version?
Postgres-R 8.3devel ;-)
Because the postmaster doesn't have direct database access. If it did,
any corruption of shared memory would risk crashing the postmaster
along with the backends.
Understood, thanks.
Most probably I better go another
Tom Lane wrote:
It should happen automatically at commit of the CREATE DATABASE ... and
you'd not be able to see the pg_database row before that anyway. So I'm
not clear on what you're worried about.
Okay, thanks. I'll have to investigate on why exactly I still get the
error, then. That's
Hi,
Tom Lane wrote:
It should happen automatically at commit of the CREATE DATABASE ... and
you'd not be able to see the pg_database row before that anyway. So I'm
not clear on what you're worried about.
I've just found the stumbling block: the -c option of psql wraps all in
a transaction,
Hi,
Tom Lane wrote:
Hm, that's an interesting point. psql's -c just shoves its whole
argument string at the backend in one PQexec(), instead of dividing
at semicolons as psql does with normal input. And so it winds up as
a single transaction because postgres.c doesn't force a transaction
Hi,
what are the assumptions PostgreSQL normally does about atomic
operations? I see sig_atomic_t is used in signal handlers. Additionally,
there is a match for a cmpxchg instruction in some solaris ports code,
but that's about what I found in the source.
Am I safe assuming that pointer
Hi,
Tom Lane wrote:
select empno, rank() over (order by salary) as srank,
rank() over (order by age) as arank
from employees order by empno;
Eeek. This seems like the worst sort of action-at-a-distance. How does
rank() know what value it's supposed to report the rank of?
All of these
Hi,
[EMAIL PROTECTED] wrote:
Ha ha... thx Tino
Yes, I think this is way to go, strange how my mind climbs the wrong
tree sometimes :)
I actually need to aquire a transaction across several dB's, check if
the conditions are right, and then modify some tables, write and remove
some triggers.
Hi,
Alvaro Herrera wrote:
1. There will be two kinds of processes, autovacuum launcher and
autovacuum worker.
Sounds similar to what I do in Postgres-R: one replication manager and
several replication workers. Those are called remote backends (which
is somewhat of an unfortunate name, IMO.)
Hi,
Alvaro Herrera wrote:
Yeah. For what I need, the launcher just needs to know when a worker
has finished and how many workers there are.
Oh, so it's not all that less communication. My replication manager also
needs to know when a worker dies. You said you are using a signal from
Hi,
Jan Wieck wrote:
The replication system I have in mind will have another field type of
the balance nature, where it will never communicate the current value
but only deltas that get applied regardless of the two timestamps.
I'd favor a more generally usable conflict resolution function
Hi,
Nice proposal. I'd support that enhancement and could make use of such
triggers in Postgres-R as well, at least to provide these triggers to
the user.
Jan Wieck wrote:
Good question. I don't know. I'd rather error on the safe side and make
it multiple states, for now I only have Normal
Hi,
Alvaro Herrera wrote:
I haven't done that yet, since the current incarnation does not need it.
But I have considered using some signal like SIGUSR1 to mean something
changed in your processes, look into your shared memory. The
autovacuum shared memory area would contain PIDs (or maybe
Hi,
Jim Nasby wrote:
Note that those terms only make sense if you limit yourself to thinking
the master is pushing data out to the slave...
I don't really get the limitation here. It's all about distinguishing
between master/slave, origin/replica, local/remote - however you want to
call it.
Alvaro Herrera wrote:
I'd suggest sticking to something closer to the current two-phase design
where you make some preliminary decision which database to send a worker
to, and then the worker determines exactly what to do once it can look
around inside the DB. Possibly we need some
Hi,
Tom Lane wrote:
I don't think there's any compelling reason for having that log message
in its current form. What about redefining it to mean postmaster is
ready to accept connections --- either with that wording, or keeping
the old wording? Then we could just put it in one place in
Hi,
Theo Schlossnagle wrote:
On Feb 4, 2007, at 1:36 PM, Jan Wieck wrote:
Obviously the counters will immediately drift apart based on the
transaction load of the nodes as soon as the network goes down. And in
order to avoid this clock confusion and wrong expectation, you'd
rather have a
Hi,
Zeugswetter Andreas ADI SD wrote:
And time based
is surely one of the important conflict resolution methods for async MM
replication.
That's what I'm questioning. Wouldn't any other deterministic, but
seemingly random abort decision be as clever as time based conflict
resolution? It
Hi,
Jan Wieck wrote:
Whatever strategy one will use, in an async multimaster there are always
cases that can be resolved by rules (last update being one of them), and
some that I can't even imagine solving so far. I guess some of the cases
will simply boil down to the application has to make
Hi,
Jan Wieck wrote:
Are we still discussing if the Postgres backend may provide support for
a commit timestamp, that follows the rules for Lamport timestamps in a
multi-node cluster?
No. And I think you know my opinion about that by now. ;-)
It seems more like we are drifting into what
Hi,
Jan Wieck wrote:
Then let me give you a little puzzle just for the fun of it.
A database containing customer contact information (among other things)
is a two node multimaster system. One is serving the customer web
portal, the other is used by the company staff including the call
Hi,
since str(n?)cat got replaced with strlcat, I fail to build PostgreSQL
(current CVS HEAD). HAVING_DECL_STRLCAT is not set, so AFAIK, the
strlcat() function from src/port should be used. However, I've read the
README there, but still don't quite know what's wrong.
The linker throws:
gcc
Hi,
Tom Lane wrote:
You mean four different object types. I'm not totally clear on bison's
scaling behavior relative to the number of productions
You really want to trade parser performance (which is *very*
implementation specific) for ease of use?
Bison generates a LALR [1] parser, which
Hi,
Florian G. Pflug wrote:
According to http://en.wikipedia.org/wiki/LR_parser processing one
token in any LR(1) parser in the worst case needs to
a) Do a lookup in the action table with the current (state, token) pair
b) Do a lookup in the goto table with a (state, rule) pair.
c) Push one
Hi,
Peter Eisentraut wrote:
Oleg Bartunov wrote:
It's not so big addition to the gram.y, see a list of commands
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/sql-commands.html.
As we still to still discuss the syntax: is there a proposal for how a
function based syntax would look like?
Hi,
Andrew Dunstan wrote:
1. The buildfarm is very heavily dependent on CVS, and any change to
anything else will be quite painful. There is no guarantee that all the
members even have SVN installed,
But you can guarantee they have CVS or even cvsup installed? That seems
dubious to me.
Hi,
[ I've CCed the monotone-devel list, as I'm sure those people are
interested, too. ]
Stefan Kaltenbrunner wrote:
Beside that - are all of the currently supported Platforms officially
supported by the proposed SCMSes ?
I can only speak for monotone. We have (had) buildbots for x86
Hi,
Andrew Dunstan wrote:
CVSup is not required, and is absent from most existing clients. I don't
use it any more since the Fedora project stopped supporting it.
..which is quite understandable, concerning the PITA compiling modula-3
gives you (or at least has given me, it still hurts).
Hi,
Andrew Dunstan wrote:
If we are worried about the size of the transition table and keeping it
in cache (see remarks from Tom upthread) then adding more keywords seems
a bad idea, as it will surely expand the table. OTOH, I'd hate to make
that a design criterion.
Yeah, me too.
Hello Richard,
you should probably have read the thread on the PostgreSQL -hackers
mailing list I've linked to... at least you didn't make Tom's point ;-)
Richard Levitte - VMS Whacker wrote:
1. Do you want to stay with CVS or do you want to move to something
else?
Most PostgreSQL
Hi,
Pavel Stehule wrote:
Functions maybe doesn't see efective, but user's cannot learn new syntax.
Are you serious? That argument speaks exactly *for* extending the
grammar. From other databases, users are used to:
CREATE TABLE ... (SQL)
CREATE INDEX ... (SQL)
CREATE FULLTEXT INDEX ...
Hi,
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Thu, 22 Feb 2007 17:38:26 +0100, Markus
Schiltknecht [EMAIL PROTECTED] said:
markus So far, I'm getting the sense that there are a lot of
markus opinions on what replacement system to use, a bit carelessly
markus
Hi,
Andrew Dunstan wrote:
O.k. everyone pay attention, I am about to agree with Greg! ;)
Greg are their tools to migrate CVS to monotone or whatever your
favorite is? The reason I ask is that I migrate the CVS to SVN every 4
hours I think it is and it isn't perfect.
monotone ships it's own
Hi,
Matthew D. Fuller wrote:
I would say that a far greater contributor in practice would simply be
frequency. If you diverge on your significant feature for 6 months,
then try to merge in upstream changes from the main dev, you will be
in hell no matter what merge algorithm you use.
Do you
Hi,
Tom Lane wrote:
Yah know, the one bit of these pitches that always sounds like pure
snake oil is the claim that they offer some kind of mechanical solution
to merge conflicts. AFAICS that has nothing to do with the SCMS in use
and everything to do with whether your diff command is
Hi,
Warren Turkal wrote:
Cvs2svn seems to make as much sense of CVS data as possible. The only real
problem I have seen is with regard to the malformed files I mentioned
earlier.
cvs2svn (1.x) still heavily relies on timestamps, which is certainly
correct in most cases. But they are
Hi,
[EMAIL PROTECTED] wrote:
I'll have to try kdiff3 - but the merge command, although it often works,
I strongly dislike when it marks up the lines as there was a conflict here
and gives you three files in the directory to choose to start from. This is
far too manual, which invites mistakes.
101 - 167 of 167 matches
Mail list logo
