ement triggers do you mean ?
I don't think we have ON COPY triggers ?
I mean
CREATE TRIGGER /name/ { BEFORE | AFTER } /event/
ON /table/ FOR EACH STATEMENT
Emmanuel
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
he
trigger was trying to move the tuple to another partition. However, I
had a problem with after row triggers that I had to call synchronously
to be able to detect the change. We will need something to tell us that
an after row trigger did not mess with the routing decision.
Emmanuel
--
Emmanue
Hannu Krosing wrote:
On Tue, 2009-11-24 at 10:08 -0500, Emmanuel Cecchet wrote:
Itagaki Takahiro wrote:
I just edited a wiki page for this discussion.
I hope it can be a help.
http://wiki.postgresql.org/wiki/Table_partitioning
I guess the problem of handling user triggers is
subset of the desired
feature set here is really remarkable when you see them all together.
Should we add the 'WITH (...) TABLESPACE tbs' options to the syntax
since they are supported?
Do we support ALTER ... SET TABLESPACE?
Emmanuel
--
Emmanuel Cecchet
Aster Data
Web: http://www.ast
lanner and executor improvements.
It would come in the future development.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
----
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
--
Sent
Itagaki Takahiro wrote:
Emmanuel Cecchet wrote:
I guess the problem of handling user triggers is still open.
If we allow triggers on partitions, badly written logic could lead to
infinite loops in routing.
Infinite loops are not a partition-related problem, no?
We can also find
it be
possible to define a view using child tables?
Emmanuel
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
raise awareness further?
/E
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Mon, Nov 23, 2009 at 9:39 AM, Emmanuel Cecchet wrote:
I think you should read the thread and the patch before making any false
statements like you did in your email.
1. The patch does not use any trigger for routing.
Whoa, whoa! I don't think that Simon
contribute a code monkey to implement your specs, why not but you will
have to convince them.
You should really think twice about the style of your emails that cast a
detestable tone to discussions on pg-hackers.
Emmanuel
On Wed, 2009-11-11 at 19:53 -0500, Emmanuel Cecchet wrote:
Hi,
Stephan Szabo wrote:
On Sun, 22 Nov 2009, Emmanuel Cecchet wrote:
As I explained to Tom, if the after row trigger is called asynchronously
I get a relcache leak on the child table at the end of the copy
operation. If the trigger is called synchronously (like a before row
trigger) it works
ons. I already tried once and I was unsuccessful. As
nothing as changed I don't see why I would be more successful this time.
Emmanuel
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
n the tuple is moved to a child table (also
allows to detect for triggers that are messing with the routing).
I would be happy to follow any recommendation for a more elegant
solution to the problem.
Emmanuel
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
--
Sent via pgsql-ha
3 (Ubuntu 4.3.3-5ubuntu4).
Let me know if you need additional info about my setup.
Emmanuel
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Then I guess that we need to fix the test.
Emmanuel
Kenneth Marshall wrote:
Without an order by, the order is not defined. The answers are the
same but the test gives a false failure because of the lack of
ordering.
Regards,
Ken
On Thu, Nov 19, 2009 at 07:54:30PM -0500, Emmanuel Cecchet
Tom Lane wrote:
Andrew Dunstan writes:
Emmanuel Cecchet wrote:
Is it just me or the union test case fails in CVS head?
The buildfarm is pretty much all green:
<http://www.pgbuildfarm.org/cgi-bin/show_status.pl>
So it looks like it's you :-)
When in
Hi,
Is it just me or the union test case fails in CVS head?
manu
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Emmanuel Cecchet writes:
Actually the list is supposed to stay around between statement
executions. You don't want to restart with a cold cache at every
statement so I really want this structure to stay in memory at a more
global level.
Cache? Why do you n
Tom Lane wrote:
Emmanuel Cecchet writes:
Tom Lane wrote:
This looks like the patch is trying to create a data structure in a
memory context that's not sufficiently long-lived for the use of the
structure. If you do this in a non-cassert build, it will seem to
work, some of the
seem to
work, some of the time, if the memory in question happens to not
get reallocated to something else.
I was using the CacheMemoryContext. Could someone tell me why this is
wrong and what should have been the appropriate context to use?
Thanks
Emmanuel
--
Emmanuel Cecchet
Aster Data
W
The following email expresses my personal opinion and does not reflect
the opinion of my employers.
Bruce Momjian wrote:
I also think the bad economy is making it harder for people/companies to
devote time to community stuff when paid work is available.
Actually the bad economy should be a b
uld be replaced with the catalog.
This implementation is only for the current 8.5 and it will not be
needed anymore once we get a fully functional partitioning in Postgres
which seems to be for a future version.
Best regards,
Emmanuel
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.co
logging related comments that do not apply here.
Looking forward to your feedback
Emmanuel
--
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com
Index: src/test/regress/parallel_schedule
===
RCS file: /home/manu/cvsrepo/pgsql
Tom Lane wrote:
Greg Stark writes:
On Wed, Nov 4, 2009 at 3:17 AM, Emmanuel Cecchet wrote:
SELECT DISTINCT ON ('1'::varchar, '1'::varchar) a FROM (SELECT 1 AS a) AS a
ORDER BY '1'::varchar, '1'::varchar, '2'::varchar;
T
or (but I guess it should):
SELECT DISTINCT ON ('1'::varchar, '2'::varchar, '1'::varchar) a FROM (SELECT 1
AS a) AS a ORDER BY '1'::varchar, '2'::varchar, '2'::varchar;
Am I misunderstanding something or is there a bug?
Thanks for th
Tom,
Emmanuel Cecchet writes:
Tom Lane wrote:
There aren't any. You can *not* put a try/catch around arbitrary code
without a subtransaction. Don't even think about it
Well then why the tests provided with the patch are working?
Because they carefully exercise o
Tom Lane wrote:
Emmanuel Cecchet writes:
- speed with error logging best effort: no use of sub-transactions but
errors that can safely be trapped with pg_try/catch (no index violation,
There aren't any. You can *not* put a try/catch around arbitrary code
without a subtransa
e every row in a sub-transaction -> is there any
real benefits compared to pg_loader?
Tom was also suggesting 'refactoring COPY into a series of steps that
the user can control'. What would these steps be? Would that be per row
and allow to discard a bad tuple?
Emmanuel
--
Emmanuel
ependent from
COPY to me.
manu
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Wed, Oct 7, 2009 at 11:39 AM, Emmanuel Cecchet wrote:
Robert Haas wrote:
On Wed, Oct 7, 2009 at 9:12 AM, Emmanuel Cecchet
wrote:
Hi all,
I think there is a misunderstanding about what the current patch is
about.
The patch includes 2 things:
- error
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan writes:
Emmanuel Cecchet wrote:
If you prefer to postpone the auto-partitioning to the next commit
fest, I can strip it from the current patch and re-submit it for the
next fest (but it's just 2 isolated me
Robert Haas wrote:
On Wed, Oct 7, 2009 at 9:12 AM, Emmanuel Cecchet wrote:
Hi all,
I think there is a misunderstanding about what the current patch is about.
The patch includes 2 things:
- error logging in a table for bad tuples in a COPY operation (see
http://wiki.postgresql.org/wiki
appelation, so
I'm going with both. But in all seriousness if this patch needs
substantial reworking (which it sounds like it does) we should
postpone it to the next CF; we are quickly running out of days, and
it's not fair to reviewers or committers to ask for new reviews of
substantia
e from a successful COPY command
or not will be left to the user.
Emmanuel
-- Emmanuel Cecchet Aster Data Systems Web: http://www.asterdata.com
d by Tom. The new format of options
has been introduced just before this patch.
I am attaching a revised version of the patch.
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
aster-copy-newsyntax-patch-8.5v6context.txt.gz
Description: GNU Zip compressed d
+m and that will do the trick.
I am attaching a copy of the file, hoping that the attachment will
arrive with the malformed terminator in your inbox!
manu
Jeff Davis wrote:
On Fri, 2009-09-25 at 10:01 -0400, Emmanuel Cecchet wrote:
Robert,
Here is the new version of the patch that applies
what
is the right approach for this.
manu
On Tue, 2009-09-22 at 18:16 -0400, Emmanuel Cecchet wrote:
If the partitioning implementation does not make progress (and does not
make it for 8.5)
Manu, not sure if you are referring to Kedar's patch I reviewed earlier
in July, but that
Robert,
Here is the new version of the patch that applies to CVS HEAD as of this
morning.
Emmanuel
On Fri, Sep 18, 2009 at 12:14 AM, Emmanuel Cecchet wrote:
Here is a new version of error logging and autopartitioning in COPY based on
the latest COPY patch that provides the new syntax
Yes, I have to update the patch following what Tom already integrated of
the COPY patch.
I will get a new version posted as soon as I can.
Emmanuel
Robert Haas wrote:
On Fri, Sep 18, 2009 at 12:14 AM, Emmanuel Cecchet wrote:
Here is a new version of error logging and autopartitioning in
auses be
simple "Var op Var" clauses. But the main thing is that a large
fraction of the patch is doing something I don't think we should try
to do.
regards, tom lane
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent vi
mandatory and be
either text, binary or csv (for now).
manu
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
anyone.
Emmanuel
Robert Haas wrote:
On Sun, Sep 20, 2009 at 2:25 PM, Emmanuel Cecchet wrote:
Tom Lane wrote:
Emmanuel Cecchet writes:
Here you will force every format to use the same set of options
How does this "force" any such thing?
As far as I und
Tom Lane wrote:
Emmanuel Cecchet writes:
Here you will force every format to use the same set of options
How does this "force" any such thing?
As far as I understand it, every format will have to handle every format
options that may exist so that they can either imple
o modify all other
formats to make sure they throw an error telling the user that this
option is not supported. I don't think this is a great design and that
it will be easy to extend.
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers ma
syntax in most other places, so why here?
There are counter-precedents even in the syntax of COPY itself:
you can't write "()" for an empty column name list, and you can't
write "()" for an empty copy_generic_option_list.
Well this one was in Robert's initial patch
ed in performance testing on that, that
would be great.
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Time: 124.303 ms
COMMIT
Time: 4.130 ms
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Here you go.
Emmanuel
Dan Colish wrote:
On Thu, Sep 17, 2009 at 02:56:07PM -0400, Emmanuel Cecchet wrote:
Dan,
My bad, I copy/pasted the hard link in output/copy.source instead of
@abs_build...@.
Here is a complete version of the patch with the fix on output/copy.source.
Emmanuel
Dan,
My bad, I copy/pasted the hard link in output/copy.source instead of
@abs_build...@.
Here is a complete version of the patch with the fix on output/copy.source.
Emmanuel
On Thu, Sep 17, 2009 at 11:07:33AM -0400, Emmanuel Cecchet wrote:
Tom Lane wrote:
I wonder though if we
(error
logging and autopartitioning) on this implementation. We might come up
with new ideas for the documentation side of things with more options.
manu
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
### Eclipse Workspace Patch 1.0
#P Postgres8.5-COPY
Index: src/test/r
Tom Lane wrote:
Emmanuel Cecchet writes:
Tom Lane wrote:
psql has MORE need to support old syntax than the backend does, because
it's supposed to work against old servers.
Well, I wonder how many users just upgrade psql vs upgrade the server.
We have establis
Pavel Stehule wrote:
Well, I wonder how many users just upgrade psql vs upgrade the server. I was
thinking that when users perform a database upgrade their application often
remain the same and therefore the server needs to support the old syntax.
Unless you are upgrading a machine where a bunch
should be
sent as is to the server as you suggest. I'll come with a patch for that
today.
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
here is that the parser does not have to be changed again if we add
new options, we just have to handle them in the COPY code (which will
probably have to be refactored at some point as it was discussed in a
previous thread).
manu
2009/9/17 Emmanuel Cecchet :
Robert Haas wrote:
I
ed for the server to still support the syntax,
is it necessary for newer version of psql to support the old syntax?
I am attaching the new version of the patch with the current
modifications addressing your comments.
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web:
decide to drop the old syntax (in 8.6?), we will be able to
clean a lot especially in psql.
Emmanuel
On Mon, Sep 14, 2009 at 2:51 PM, Emmanuel Cecchet wrote:
This looks good. Shoud I try to elaborate on that for the patch with error
logging and autopartitioning in COPY?
That make s
Robert Haas wrote:
On Mon, Sep 14, 2009 at 2:51 PM, Emmanuel Cecchet wrote:
This looks good. Shoud I try to elaborate on that for the patch with error
logging and autopartitioning in COPY?
That make sense to me. You shouldn't need to do anything else in
gram.y; whatever you wa
, or someone else is welcome to pick it up.
It's on my git repo as well, as usual.
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Greg Smith wrote:
On Fri, 11 Sep 2009, Emmanuel Cecchet wrote:
I guess the problem with extra or missing columns is to make sure
that you know exactly which data belongs to which column so that you
don't put data in the wrong columns which is likely to happen if this
is fully auto
help with the partitioning
implementation and/or testing of that feature since this is of interest
for Aster too.
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
option with different values. The last value prevails?
I know that this example looks stupid but when you have a lot of options
it sometimes happen that you put twice an option with different values
(that happens with some JDBC driver options...).
manu
--
Emmanuel Cecchet
Aster Data Systems
d
how you figure out which rows are missing or extra.
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
rt the new extension (and it will have to be
documented) so it should not make a big difference whether it is
explicitly part of the command grammar or a set of generic options.
manu
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgs
n example.
Emmanuel
/
/
Emmanuel Cecchet writes:
The new syntax could look like:
COPY /tablename/ [ ( /column/ [, ...] ) ]
FROM { '/filename/' | STDIN }
[ [, BINARY ]
[, OIDS ]
[, DELIMITER [ AS ] '/delimiter/' ]
[, NULL [ AS ]
#x27; ]
[ FORCE NOT NULL (/column/ [, ...]) ]
[, ERRORS { SKIP |
LOG INTO { tablename | 'filename' }
[ LABEL label_name ]
[ KEY key_name ]
[ MAX ERRORS /count/ ] } ]
Is this what you had in mind?
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
Tom Lane wrote:
It might be time to switch COPY over to a more easily extensible
option syntax, such as we just adopted for EXPLAIN.
Could you point me to the thread detailing the extensible option syntax
for EXPLAIN? Is that new to 8.5?
Thanks
Emmanuel
--
Emmanuel Cecchet
Aster Data
ferent files and from the
file names it would be easy to identify the faulty client. I am not sure
how you would use the pid to identify the faulty client more easily?
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-h
hat if you have
a deep tree hierarchy, you don't necessarily have to insert at the top
of the tree, you can start anywhere down the tree.
Once we have the full partitioning support (in 8.5?), we can probably
re-use some of their mechanism to route directly the tuple to the ri
e --> copy_logging_table_name
error_logging_tuple_label --> don't know what this is for, see above
error_logging_tuple_partition_key --> don't know what this is for, see above
tuple_routing_in_copy --> copy_partitioning
tuple_routing_cache_size --> copy_partitioning_cache_size
Hi David,
My C isn't all that great, to put it mildly, but I noticed C++-style
//comments like this, which we don't use.
Ok, I will fix that.
Are these dependent on each other, or could they be reviewed, etc.
separately?
The code implementing the functionality are independent (separate
The attached patch contains both contribs as well as unit tests. I will
submit shortly the new patch at commitfest.postgresql.org.
Thanks in advance for your feedback,
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
aster-copy-improvements-patch-8.5v3.txt.gz
Tom Lane wrote:
Emmanuel Cecchet writes:
I got an error like this:
ERROR: xlog flush request 1/C121E998 is not satisfied --- flushed only to
1/BCBCB440
CONTEXT: writing block 529 of relation 1663/233690/1247
WARNING: could not write block 529 of 1663/233690/1247
DETAIL
Hi,
I got an error like this:
ERROR: xlog flush request 1/C121E998 is not satisfied --- flushed only to
1/BCBCB440
CONTEXT: writing block 529 of relation 1663/233690/1247
WARNING: could not write block 529 of 1663/233690/1247
DETAIL: Multiple failures --- write error might be permanent.
Th
the temporary schema that is locked
away in the prepared transaction. Isn't that breaking the assumption
that each session should have a unique schema for its temp tables?
Thanks in advance for your insights.
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
Tom Lane wrote:
Emmanuel Cecchet writes:
But when the transaction prepares, we know that. What would prevent us
to do at prepare time the same cleanup that commit does?
The entire point of PREPARE is that it's *not* committed yet.
Agreed but all objects that were create
Tom Lane wrote:
Emmanuel Cecchet writes:
Tom Lane wrote:
True, but the problem is that the tuple might still be live to (some
snapshots in) that transaction, so we can't inject a duplicate tuple
without risking confusing it. In this particular case that isn't an
issue b
Tom Lane wrote:
True, but the problem is that the tuple might still be live to (some
snapshots in) that transaction, so we can't inject a duplicate tuple
without risking confusing it. In this particular case that isn't an
issue because the transaction is done executing, but the tqual.c
rules don
Tom Lane wrote:
Emmanuel Cecchet writes:
Take PG 8.3.0 and try:
BEGIN;
CREATE TEMP TABLE foo (x int) ON COMMIT DROP;
PREPARE TRANSACTION 't1';
[BEGIN;] <-- doesn't really matter if you start a new transaction or not
CREATE TEMP TABLE foo (x int); <-- blocks until t1 com
27;foo' for some reason I don't
really get.
Any suggestion on what should be done differently for temp tables there?
Thanks,
Emmanuel
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: m...@frogthinker.org
Skype:
From: Tom Lane [...@sss.pgh.pa.us]
Subject: Re: [HACKERS] Wrong stats for empty tables
"Emmanuel Cecchet" writes:
> Is this a bug?
No, it's intentional.
So what is the rationale behind not being able to use indexes and optimizing
empty tables as in the following examp
ar (cost=0.00..0.00 rows=1 width=4)
(1 row)
This is a real problem if you have a lot of empty child tables. Postgres will
not optimize correctly queries in the presence of empty child tables.
Is this a bug?
Thanks for your help,
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.ast
mplemented via triggers in the first place.
regards, tom lane
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.or
executed first and others last?
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: m...@frogthinker.org
Skype: emmanuel_cecchet
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
.
Regards,
--
Kedar.
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
marcin mank wrote:
Use plain oids or regclass values, not a text column, if you are trying
to store table identities.
wouldn`t oids change on dump/reload?
I don't know. I'd also be interested to know if there is a difference if
we use pg_restore with a binary format or sql dump, or if t
Tom Lane wrote:
Emmanuel Cecchet writes:
It looks like the behavior of regclass is not consistent when table
names are quoted. The name is returned without the quotes if the name is
lower case with eventual trailing numbers, otherwise it is returned with
quotes.
It's intent
tcolumnVIEW"
16422 | testcolumnview
16425 | testcolumnview2
16428 | "1test2abc"
16431 | "1test2"
16434 | "1test"
(9 rows)
Is this a bug?
manu
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
f this kind of approah is that trigger code can be made
genric for any kind of partition table.
Thanks,
Amit
Persistent Systems,
www.persistentsys.com
On 1/23/09, Emmanuel Cecchet wrote:
Amit,
You might want to put this on the
http://wiki.postgresql.org/wiki/Table_partitioning wik
hanks,
Emmanuel
Hi Emmanuel,
Please find my comments in-lined:
On 1/23/09, *Emmanuel Cecchet* <mailto:m...@frogthinker.org>> wrote:
Amit,
You might want to put this on the
http://wiki.postgresql.org/wiki/Table_partitioning wiki page.
Sure.
How does your timeline look
ioned tables.
Please feel free to post your comments and suggestions.
Thanks,
Amit
Persistent Systems
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
side, but I
still have not seen a single use case in industry where this was a
requirement (but my db experience is probably narrow).
Have nice serializable holidays ;-)
manu
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinke
transaction. Hopefully we will be able to come up with a working
solution in 8.5.
Thanks for your help,
Emmanuel
Emmanuel Cecchet wrote:
I just saw that this new patch was not considered because the previous
version ended being rejected.
Note that this version of the patch aims at
good
admission control on top of the GCS (in the application).
I am now off for the holidays.
Cheers,
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Jeff Davis wrote:
On Tue, 2008-12-23 at 00:42 -0500, Emmanuel Cecchet wrote:
I still don't
get why people would use SERIALIZABLE since there is no efficient
implementation of it.
If they need true serializable transactions, and don't care about
efficiency.
Is there such
still have in
serializable transactions. Why don't users program the application to
deal with a lower isolation (actually I think they do)?
But I am probably missing the point which was to fix the doc?
Emmanuel
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & C
a user expects a
cluster to behave like a single database instance.
Happy holidays,
Emmanuel
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: m...@frogthinker.org
Skype: emmanuel_cecchet
--
Sent via pgsql-hackers mailing
noted in the documentation. I don't know if there's any way to fix
this without killing performance.
-Kevin
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: m...@frogthinker.org
Skype: emmanuel_cecchet
ing window
for concurrent transactions. The writeset extraction mechanisms have had
too many limitations so far to allow the use of certification-based
replication in production (AFAIK).
Good luck with Postgres-R.
Emmanuel
Emmanuel Cecchet wrote:
What the application is going to see is a f
with a constructive proposal that
does not offend anyone, I think that it is best that I do not contribute
anything to the wiki anymore.
Best,
Emmanuel
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
n arbitrary depth of partitions even though
partition management might become slightly more complex/
I will try to integrate the comments as I see them on the mailing list
but feel free also to update the wiki page with your thoughts and use
cases.
Thanks again for the feedback,
Emmanuel
--
Em
1 - 100 of 138 matches
Mail list logo
