On 19 October 2010 05:21, Andrew Dunstan wrote:
>
>
> On 10/18/2010 10:52 AM, Tom Lane wrote:
>>
>> We could possibly deal with enum types that follow the existing
>> convention if we made the cache entry hold a list of all the original,
>> known-to-be-sorted OIDs. (This could be reasonably compa
On 19 October 2010 05:21, Andrew Dunstan wrote:
>
>
> On 10/18/2010 10:52 AM, Tom Lane wrote:
>>
>> We could possibly deal with enum types that follow the existing
>> convention if we made the cache entry hold a list of all the original,
>> known-to-be-sorted OIDs. (This could be reasonably compa
On Tue, Oct 19, 2010 at 10:19, Thom Brown wrote:
> On 19 October 2010 05:21, Andrew Dunstan wrote:
>>
>>
>> On 10/18/2010 10:52 AM, Tom Lane wrote:
>>>
>>> We could possibly deal with enum types that follow the existing
>>> convention if we made the cache entry hold a list of all the original,
>>
(2010/10/14 1:52), Tom Lane wrote:
Robert Haas writes:
On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
That's all true, but you have to consider how much the obstacle actually
gets in their way versus how painful it is on your end to create and
maintain the obstacle. �I don't think this pro
Hi,
Josh Berkus writes:
> It is critical that we make replication easier to set up, administrate and
> monitor than it currently is. In my conversations with people, this is more
> important to our users and the adoption of PostgreSQL than synchronous
> replication is.
I want to say a big big +
On Mon, Oct 18, 2010 at 8:37 PM, Dimitri Fontaine
wrote:
> Here's another version of the patch, v3. Changes:
CREATE EXTENSION is interesting feature!
I just compiled it and tested it via SQL commands. Here is a quick report.
* There are some compiler warnings. You might be missing something in
c
Itagaki Takahiro writes:
> CREATE EXTENSION is interesting feature!
> I just compiled it and tested it via SQL commands. Here is a quick
> report.
Thanks for you time and interest!
> * There are some compiler warnings. You might be missing something in
> copyfuncs and equalfuncs.
>
> copyfu
Josh Berkus wrote:
Hackers,
What purpose is served, exactly, by max_wal_senders?
In order for a standby to connect, it must have a superuser login, and
replication connections must be enabled in pg_hba.conf. How is having
one more setting in one more file you have to enable on the master
be
On Tue, Oct 19, 2010 at 13:14, Stefan Kaltenbrunner
wrote:
> Josh Berkus wrote:
>>
>> Hackers,
>>
>> What purpose is served, exactly, by max_wal_senders?
>>
>> In order for a standby to connect, it must have a superuser login, and
>> replication connections must be enabled in pg_hba.conf. How is
On Tue, Oct 19, 2010 at 1:46 AM, Peter Eisentraut wrote:
> The comment code refactoring c10575ff005c330d0475345621b7d381eb510c48
> broke comments on composite type attributes:
>
> COMMENT ON COLUMN foo.a is 'test';
> ERROR: 42809: "foo" is a composite type
> LOCATION: heap_openrv, heapam.c:1110
Magnus Hagander wrote:
On Tue, Oct 19, 2010 at 13:14, Stefan Kaltenbrunner
wrote:
Josh Berkus wrote:
Hackers,
What purpose is served, exactly, by max_wal_senders?
In order for a standby to connect, it must have a superuser login, and
replication connections must be enabled in pg_hba.conf. H
On Oct 19, 2010, at 4:34 AM, KaiGai Kohei wrote:
> (2010/10/14 1:52), Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
That's all true, but you have to consider how much the obstacle actually
gets in their way versus how painful it is on your
Itagaki Takahiro writes:
> * There are some compiler warnings. You might be missing something in
> copyfuncs and equalfuncs.
Fixed in v4, attached.
> * There might be some bugs in pg_dump:
> pg_dump: schema with OID 2200 does not exist, but is needed for object
> 16411
Fixed in v4, attached.
T
On Oct 19, 2010, at 8:33 AM, Dimitri Fontaine wrote:
> I didn't realise that using SPI would mean dumping the all script in
> case of even NOTICEs. May be we want to protect against that in the
> CREATE EXTENSION case, but I didn't have a look at how to do it. Do we
> want CREATE EXTENSION to be m
Robert Haas writes:
> I don't see why. I think the real action item here is to remove =>
> from hstore.
As input, consider that lots of extensions will create types that are
only a shell at the moment of the CREATE TYPE, and for each of those
types you will see the (potentially > 1000 lines long
(2010/10/19 21:31), Robert Haas wrote:
On Oct 19, 2010, at 4:34 AM, KaiGai Kohei wrote:
(2010/10/14 1:52), Tom Lane wrote:
Robert Haas writes:
On Wed, Oct 13, 2010 at 11:45 AM, Tom Lane wrote:
That's all true, but you have to consider how much the obstacle actually
gets in their way vers
On Tue, Oct 19, 2010 at 9:07 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I don't see why. I think the real action item here is to remove =>
>> from hstore.
>
> As input, consider that lots of extensions will create types that are
> only a shell at the moment of the CREATE TYPE, and for
Excerpts from Magnus Hagander's message of mar oct 19 05:23:31 -0300 2010:
>
> He certainly could, but github provides more features and a nicer look
> :-) And since it's git, it doesn't matter where the repo is.
Yeah. If you have a checked out copy of the GIT repo (preferably one
with the "mast
Bruce Momjian writes:
> Tom Lane wrote:
>> Bruce Momjian writes:
>>> Looking at the pg_upgrade code some more, I found that it was not
>>> removing the PG_VERSION file when deleting <= 8.4 tablespace files.
>>> This might confuse administrators so the attached patch adds the removal
>>> of PG_VE
On Mon, Oct 18, 2010 at 04:13:04PM +0100, Mark Cave-Ayland wrote:
> David Fetter wrote:
>
> >>For my vote, I'd prefer either the Oid of a custom type or an array
> >>of Oid, Datum pairs - i.e. something we can extend in the future if
> >>required.
> >
> >This sounds a lot like a foreign key to ano
Andres Freund wrote:
> Here is a proposed patch which enables cancellation of $subject.
Cool. Some enhancements we'd like to do to Serializable Snapshot
Isolation (SSI), should the base patch make it in, would require
this capability.
> Currently it does *not* report any special error messa
On Tue, Oct 19, 2010 at 10:18 AM, Kevin Grittner
wrote:
> Andres Freund wrote:
>
>> Here is a proposed patch which enables cancellation of $subject.
>
> I'll take a look when I can, but it may be a couple weeks from now.
How about adding it to
https://commitfest.postgresql.org/action/commitfest_
Dimitri Fontaine writes:
> Robert Haas writes:
>> I don't see why. I think the real action item here is to remove =>
>> from hstore.
> As input, consider that lots of extensions will create types that are
> only a shell at the moment of the CREATE TYPE, and for each of those
> types you will se
KaiGai Kohei writes:
> (2010/10/19 21:31), Robert Haas wrote:
>> I think you're still misreading it.
> Hmm. In my understanding, it seems to me he concerned about possible leaky
> estimate functions, so he mentioned the horrible performance degrading, if
> we don't allow to execute these function
On Sat, Oct 16, 2010 at 12:59 PM, Terry Laurenzo wrote:
> - It is directly iterable without parsing and/or constructing an AST
> - It is its own representation. If iterating and you want to tear-off a
> value to be returned or used elsewhere, its a simple buffer copy plus some
> bit twiddli
On 10/19/2010 10:44 AM, Robert Haas wrote:
On Sat, Oct 16, 2010 at 12:59 PM, Terry Laurenzo wrote:
- It is directly iterable without parsing and/or constructing an AST
- It is its own representation. If iterating and you want to tear-off a
value to be returned or used elsewhere, its
Tom Lane writes:
> Only if the script is intentionally noisy. The right fix here is
> probably to bump up the min message level while running the script.
You mean doing that from the SQL script itself (using SET) or in the
pg_execute_from_file() code? My guess is the former, but...
Regards,
--
Robert Haas wrote:
> On Thu, Oct 7, 2010 at 11:52 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> Proposed doc patch attached.
> >
> > "discusesed"? ?Otherwise +1
>
> Woops, thanks. Committed with that change. I back-patched it back to
> 8.3, which is as far as it applied with only minor conf
3) 3-rd boolean column (amopopr, amopfamily, amoporder)
- could be two records per operator
+ operator could be used in both roles
+ strategy number could be different for different roles
How can #3 work at all? It's ignoring a couple of critical index
columns. In particular, I be
Thinking about it that way, perhaps we could add an integer column
amop_whats_it_good_for that gets used as a bit field. That wouldn't
require changing the index structure, although it might break some
other things.
OPERATOR strategy_number ( op_type [ , op_type ] ) [ FOR { SEARCH |
ORDER } [,
Josh Berkus wrote:
It is critical that we make replication easier to set up, administrate
and monitor than it currently is. In my conversations with people,
this is more important to our users and the adoption of PostgreSQL
than synchronous replication is.
You should enjoy one of the patches
Agreed. BSON was born out of implementations that either lacked arbitrary
precision numbers or had a strong affinity to an int/floating point way of
thinking about numbers. I believe that if BSON had an arbitrary precision
number type, it would be a proper superset of JSON.
As an aside, the max
Greg Smith wrote:
> A.M. wrote:
> > Perhaps a simpler tool could run a basic fsyncs-per-second test and prompt
> > the DBA to check that the numbers are within the realm of possibility.
> >
>
> This is what the test_fsync utility that already ships with the database
> should be useful for. T
Cool, will take a look. Thanks!
--- On Tue, 19/10/10, Itagaki Takahiro wrote:
From: Itagaki Takahiro
Subject: Re: [HACKERS] PL/JS
To: "Terri Laurenzo"
Cc: "Greg" , "pgsql-hackers@postgresql.org"
Date: Tuesday, 19 October, 2010, 3:18
On Tue, Oct 19, 2010 at 9:04 AM, Terri Laurenzo wrote:
>
On Oct 19, 2010, at 11:22 AM, Bruce Momjian wrote:
> Greg Smith wrote:
>> A.M. wrote:
>>> Perhaps a simpler tool could run a basic fsyncs-per-second test and prompt
>>> the DBA to check that the numbers are within the realm of possibility.
>>>
>>
>> This is what the test_fsync utility that alr
combination of parameters is one that it can handle. I'm thinking
perhaps in lieu of a boolean, we can add another indexam method which,
if not InvalidOid, gets called when we're wondering about whether a
given clause is something that the index can order by. Although
knngist focuses on a the OR
Dimitri Fontaine writes:
> Tom Lane writes:
>> Only if the script is intentionally noisy. The right fix here is
>> probably to bump up the min message level while running the script.
> You mean doing that from the SQL script itself (using SET) or in the
> pg_execute_from_file() code? My guess i
You should enjoy one of the patches we're furiously working on then,
which is aiming at some of the administration and monitoring pieces
here.
Great, glad to hear it! Would you be willing to go into detail?
I have my own grand vision of how easy replication should be to
setup too.
So, sha
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> Looking at the pg_upgrade code some more, I found that it was not
> >>> removing the PG_VERSION file when deleting <= 8.4 tablespace files.
> >>> This might confuse administrators so the attached patch a
Josh Berkus wrote:
*shrug*. Robert asked me to write it up for the list based on the
discussions around synch rep. Now you're going to bash me for doing so?
Sorry, next time I'll make sure to bash Robert too. I don't have any
problems with the basic ideas you're proposing, just concerns abo
Stefan, Dimitri,
> I disagree - limiting the maximum number of replication connections is
> important for my usecases.
Can you explain more? I clearly don't understand your use case.
If we want something fixed *now*, should we perhaps just bump the
*default* value for max_wal_senders to 5 or
Josh Berkus wrote:
Under what bizarre set of circumstances would anyone have runaway
connections from replicas to the master?
Cloud computing deployments where additional replicas are brought up
automatically in response to demand. It's easy to imagine a situation
where a standby instance is
Tom Lane writes:
> You could argue that either way I guess. The script knows what it
> needs, but OTOH just about every extension there is will probably
> be generating useless NOTICEs unless something is done, so maybe
> the extension management code should take care of it for them.
Either way
Excerpts from Dimitri Fontaine's message of dom oct 17 16:30:47 -0300 2010:
> The bulk of it is now short enough to be inlined in the mail, and if you
> have more comments I guess they'll be directed at this portion of the
> patch, so let's make it easy:
>
> /*
> * We abuse some internal
Excerpts from Dimitri Fontaine's message of vie oct 15 16:15:23 -0300 2010:
> The cfparser patch didn't change, the current version is still v1.
Hmm, this needs some cleanup; the comments still talk about the old
function name; and about just the recovery.conf file.
--
Álvaro Herrera
The Postg
A.M. wrote:
>
> On Oct 19, 2010, at 11:22 AM, Bruce Momjian wrote:
>
> > Greg Smith wrote:
> >> A.M. wrote:
> >>> Perhaps a simpler tool could run a basic fsyncs-per-second test and
> >>> prompt the DBA to check that the numbers are within the realm of
> >>> possibility.
> >>>
> >>
> >> This
Dimitri, Greg,
I want to say a big big +1 here. The way replication and PITR setup are
implemented now are a very good prototype, it's time to consolidate and
get to something usable by normal people, as opposed to PostgreSQL full
time geeks.
Well, one thing to be addressed is separating the P
On 10/19/2010 09:06 AM, Greg Smith wrote:
I think Magnus's idea to bump the default to 5 triages the worst of the
annoyance here, without dropping the feature (which has uses) or waiting
for new development to complete. I'd be in favor of just committing
that change right now, before it gets for
Alvaro Herrera writes:
> The error message wording needs some work; maybe
> errmsg("file \"%s\" could not be executed", filename)
[...]
> I happened to notice that there are several pieces of code that are
> calling SPI_connect and SPI_finish without checking the return value,
> notably the
Alvaro Herrera writes:
> Hmm, this needs some cleanup; the comments still talk about the old
> function name; and about just the recovery.conf file.
Ah yes, thinking it's an easy patch is not helping. Please find attached
a revised version of it.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.
Absolutely. For a synch standby, you can't tolerate any standby delay
at all. This means that anywhere from 1/4 to 3/4 of queries on the
standby would be cancelled on any high-traffic OLTP server. Hence,
"useless".
Don't agree with your numbers there and you seem to be assuming no
workaroun
On 10/19/2010 12:21 AM, Andrew Dunstan wrote:
On 10/18/2010 10:52 AM, Tom Lane wrote:
We could possibly deal with enum types that follow the existing
convention if we made the cache entry hold a list of all the original,
known-to-be-sorted OIDs. (This could be reasonably compact and cheap t
The cause of bug #5716 is that preprocess_targetlist is trying to get
away with creating a whole-row variable marked with type RECORDOID,
even in cases where a specific composite type is known for the
referenced RTE. This fails because now we might have non-equal Vars
representing the same RTE att
On Sat, Oct 16, 2010 at 8:42 PM, Oleg Bartunov wrote:
> Marios,
>
> you're right. There are several reasons for poor documentation, but of
> course,
> no excuse, we do need good docs any way ! It's very nice you're willing to
> write one, since it's always better seen from outside of development.
On Mon, Oct 18, 2010 at 4:31 AM, Fujii Masao wrote:
> But, even though we will have done that, it should be noted that WAL in
> A might be ahead of that in B. For example, A might crash right after
> writing WAL to the disk and before sending it to B. So when we restart
> the old master A as the s
I index these structures in gist:
typedef struct {
> uint8 type_flag;
> float8 xi;
> float8 yi;
> Timestamp ti;
> float8 xe;
> float8 ye;
> Timestamp te;
> int32 id;
> } typ_s_flagged;
>
> typedef struct {
> uint8 type_flag;
> float8 xl;
> float8 yl;
>
On Tue, Oct 19, 2010 at 9:16 AM, Josh Berkus wrote:
> Well, one thing to be addressed is separating the PITR functionality from
> replication. PITR needs a lot of features -- timelines, recovery stop
> points, etc. -- which replication doesn't need or want. I think that
> focussing on streaming
Greg,
> The way things stand you *always* need archived logs. Even if you have
> streaming set up it might try to use archived logs if it falls too far
> behind.
Actually, you don't. If you're willing to accept possible
desynchronization and recloning of the standbys, then you can skip the
archi
On Mon, Oct 18, 2010 at 6:05 PM, Greg Stark wrote:
> On Mon, Oct 18, 2010 at 1:27 PM, Robert Haas wrote:
>>> It'd be kinda cool if we had it, but the work required to get there
>>> seems far out of proportion to the benefits ...
>>
>> I agree. I think that's backing into the problem from the wro
On Tue, Oct 19, 2010 at 12:09 PM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> You could argue that either way I guess. The script knows what it
>> needs, but OTOH just about every extension there is will probably
>> be generating useless NOTICEs unless something is done, so maybe
>> the extens
On Tue, Oct 19, 2010 at 12:18 PM, Josh Berkus wrote:
> On 10/19/2010 09:06 AM, Greg Smith wrote:
>>
>> I think Magnus's idea to bump the default to 5 triages the worst of the
>> annoyance here, without dropping the feature (which has uses) or waiting
>> for new development to complete. I'd be in
On Tue, Oct 19, 2010 at 02:52:01PM -0400, Robert Haas wrote:
> Well, temp tables really want a separate set of XIDs with a separate
> CLOG, too. Admittedly, they don't necessarily need WAL, if you can
> make them work without catalog entries, but that's not so easy either.
At one point there was
On Tue, Oct 19, 2010 at 3:01 PM, Martijn van Oosterhout
wrote:
> On Tue, Oct 19, 2010 at 02:52:01PM -0400, Robert Haas wrote:
>> Well, temp tables really want a separate set of XIDs with a separate
>> CLOG, too. Admittedly, they don't necessarily need WAL, if you can
>> make them work without cat
On Mon, 2010-10-18 at 22:12 -0500, Kevin Grittner wrote:
> Hmmm... When Joe was looking at the patch he exposed an intermittent
> problem with btree indexes which turned out to be related to improper
> handling of the predicate locks during index page clean-up caused by a
> vacuum. Easy to fix on
On Tue, Oct 19, 2010 at 11:22 AM, Terry Laurenzo wrote:
> Agreed. BSON was born out of implementations that either lacked arbitrary
> precision numbers or had a strong affinity to an int/floating point way of
> thinking about numbers. I believe that if BSON had an arbitrary precision
> number ty
Robert Haas writes:
> On Tue, Oct 19, 2010 at 12:09 PM, Dimitri Fontaine
> wrote:
>> Either way is the key here too, so please find attached a revised (v5)
>> patch which will force log_min_messages and client_min_messages to
>> WARNING while the script is run.
> It seems good to do this in the
2010/10/19 Teodor Sigaev :
>>> Thinking about it that way, perhaps we could add an integer column
>>> amop_whats_it_good_for that gets used as a bit field. That wouldn't
>>> require changing the index structure, although it might break some
>>> other things.
>
>> OPERATOR strategy_number ( op_type
On Tue, 2010-10-19 at 09:36 -0700, Josh Berkus wrote:
> >> Absolutely. For a synch standby, you can't tolerate any standby delay
> >> at all. This means that anywhere from 1/4 to 3/4 of queries on the
> >> standby would be cancelled on any high-traffic OLTP server. Hence,
> >> "useless".
> >
> >
On Tue, Oct 19, 2010 at 1:46 PM, Marios Vodas wrote:
> I index these structures in gist:
>
>> typedef struct {
>> uint8 type_flag;
>> float8 xi;
>> float8 yi;
>> Timestamp ti;
>> float8 xe;
>> float8 ye;
>> Timestamp te;
>> int32 id;
>> } typ_s_flagged;
>>
>> typede
Robert Haas writes:
> On Tue, Oct 19, 2010 at 12:18 PM, Josh Berkus wrote:
>> On 10/19/2010 09:06 AM, Greg Smith wrote:
>>> I think Magnus's idea to bump the default to 5 triages the worst of the
>>> annoyance here, without dropping the feature (which has uses) or waiting
>>> for new development
On Oct 19, 2010, at 12:17 PM, Robert Haas wrote:
> I think we should take a few steps back and ask why we think that
> binary encoding is the way to go. We store XML as text, for example,
> and I can't remember any complaints about that on -bugs or
> -performance, so why do we think JSON will be
On Tue, Oct 19, 2010 at 11:22 AM, Terry Laurenzo wrote:
> Perhaps we should enumerate the attributes of what would make a good binary
> encoding?
Not sure if we're discussing the internal storage format or the binary
send/recv format, but in my humble opinion, some attributes of a good
internal f
Hi,
Boszormenyi Zoltan írta:
> There is one problem with the patch, it doesn't survive
> "make check". One of the regression tests fails the
> Assert(!cur_em->em_is_child);
> line in process_equivalence() in equivclass.c, but I couldn't
> yet find it what causes it. The "why" is vaguely clear:
Excerpts from Dimitri Fontaine's message of mar oct 19 13:09:47 -0300 2010:
> Tom Lane writes:
> > You could argue that either way I guess. The script knows what it
> > needs, but OTOH just about every extension there is will probably
> > be generating useless NOTICEs unless something is done, so
Boszormenyi Zoltan writes:
> The problem is with the two functions in path/equivclass.c,
> as process_equivalance() and those functions are all walk
> the tree, and the current RBTree code can only deal with
> one walk at a time. We need to push/pop the iterator state
> to be able to serve more th
On Tue, Oct 19, 2010 at 12:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 19, 2010 at 12:18 PM, Josh Berkus wrote:
>>> On 10/19/2010 09:06 AM, Greg Smith wrote:
I think Magnus's idea to bump the default to 5 triages the worst of the
annoyance here, without dropping the fea
On Tue, 19 Oct 2010, Marios Vodas wrote:
On Sat, Oct 16, 2010 at 8:42 PM, Oleg Bartunov wrote:
Marios,
you're right. There are several reasons for poor documentation, but of
course,
no excuse, we do need good docs any way ! It's very nice you're willing to
write one, since it's always better
On Tue, Oct 19, 2010 at 3:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Oct 19, 2010 at 12:18 PM, Josh Berkus wrote:
>>> On 10/19/2010 09:06 AM, Greg Smith wrote:
I think Magnus's idea to bump the default to 5 triages the worst of the
annoyance here, without dropping the feat
On Tue, Oct 19, 2010 at 3:40 PM, Joseph Adams
wrote:
> On Tue, Oct 19, 2010 at 3:17 PM, Robert Haas wrote:
>> I think we should take a few steps back and ask why we think that
>> binary encoding is the way to go. We store XML as text, for example,
>> and I can't remember any complaints about tha
>> Yes. This isn't just a numeric parameter; it's also a boolean
>> indicating "do I want to pay the overhead to be prepared to be a
>> replication master?".
Since this is the first time I've heard of the overhead, it would be
hard for me to have taken that into consideration. If there was
di
On Tue, Oct 19, 2010 at 12:03 PM, Robert Haas wrote:
> The trick is that it would require us to have two pg_class tables, two
> pg_attribute tables, two pg_attrdef tables, etc.: in each case, one
> permanent and one temporary. I am not sure how complex that will turn
> out to be.
Tom suggested u
On Tue, Oct 19, 2010 at 10:23 PM, Robert Haas wrote:
> Is pg_type.typlen set correctly?
>
Are you refering to table pg_type?
If yes, those type structures exist only in c I didn't write any in-out
functions, so they don't exist in sql level.
I pass a different data type (which exists in sql) to
On Tue, Oct 19, 2010 at 2:46 PM, Robert Haas wrote:
> On Tue, Oct 19, 2010 at 3:40 PM, Joseph Adams
> wrote:
> > On Tue, Oct 19, 2010 at 3:17 PM, Robert Haas
> wrote:
> >> I think we should take a few steps back and ask why we think that
> >> binary encoding is the way to go. We store XML as t
I spent yesterday writing a new tool pg_rawdump (which will be released as
open source in due course), which takes the table files in an arbitrary
pgsql database, and is able to transform those back into tables (including
toast values).
In the course of doing this (a customer needed it because he
2010/10/19 Greg Stark :
> On Tue, Oct 19, 2010 at 12:03 PM, Robert Haas wrote:
>> The trick is that it would require us to have two pg_class tables, two
>> pg_attribute tables, two pg_attrdef tables, etc.: in each case, one
>> permanent and one temporary. I am not sure how complex that will turn
On Tue, Oct 19, 2010 at 12:17 PM, Robert Haas wrote:
> I think we should take a few steps back and ask why we think that
> binary encoding is the way to go. We store XML as text, for example,
> and I can't remember any complaints about that on -bugs or
> -performance, so why do we think JSON will
>
> After spending a week in the morass of this, I have to say that I am less
> certain than I was on any front regarding the text/binary distinction. I'll
> take some time and benchmark different cases. My hypothesis is that a well
> implemented binary structure and conversions will add minimal
On Tue, Oct 19, 2010 at 1:12 PM, Stephen R. van den Berg wrote:
> In order to simplify recovery at this point (enormously), it would
> have been very helpful (at almost negligible cost), to have the name
> of the table, the name of the columns, and the types of the
> columns available.
>
> Why don
2010/10/19 Greg Stark :
> On Tue, Oct 19, 2010 at 12:17 PM, Robert Haas wrote:
>> I think we should take a few steps back and ask why we think that
>> binary encoding is the way to go. We store XML as text, for example,
>> and I can't remember any complaints about that on -bugs or
>> -performance
Greg Stark wrote:
>On Tue, Oct 19, 2010 at 1:12 PM, Stephen R. van den Berg wrote:
>> In order to simplify recovery at this point (enormously), it would
>> have been very helpful (at almost negligible cost), to have the name
>> of the table, the name of the columns, and the types of the
>> columns
In bug #5717, Richard Huxton complains that a domain declared like
CREATE DOMAIN mynums numeric(4,2)[1];
doesn't work properly, ie, the typmod isn't enforced in places where
it reasonably ought to be. I dug into this a bit, and found that there
are more worms in this can than I first expec
Jeff Davis wrote:
> I briefly looked into this when I woke up this morning, and I
> think I'm close. I can reproduce it every time, so I should be
> able to fix this as soon as I can find some free time (tomorrow
> night, probably).
OK, I'll focus on other areas.
> I might also be able to he
Greg Stark writes:
> On Tue, Oct 19, 2010 at 12:03 PM, Robert Haas wrote:
>> The trick is that it would require us to have two pg_class tables, two
>> pg_attribute tables, two pg_attrdef tables, etc.: in each case, one
>> permanent and one temporary. I am not sure how complex that will turn
>> o
Terry Laurenzo writes:
> After spending a week in the morass of this, I have to say that I am less
> certain than I was on any front regarding the text/binary distinction. I'll
> take some time and benchmark different cases. My hypothesis is that a well
> implemented binary structure and convers
"Stephen R. van den Berg" writes:
> In order to simplify recovery at this point (enormously), it would
> have been very helpful (at almost negligible cost), to have the name
> of the table, the name of the columns, and the types of the
> columns available.
> Why don't we insert that data into the
Greg Stark writes:
> The elephant in the room is if the binary encoded form is smaller then
> it occupies less ram and disk bandwidth to copy it around.
It seems equally likely that a binary-encoded form could be larger
than the text form (that's often true for our other datatypes).
Again, this i
On Tue, Oct 19, 2010 at 3:45 PM, Tom Lane wrote:
> Relcache entries alone are not gonna work. There is way too much stuff
> that assumes that tables are correctly represented in the system
> catalogs.
>
Well we're talking about multiple things now. In the global temporary
table case they *are* p
On Tue, Oct 19, 2010 at 4:51 PM, Tom Lane wrote:
> Terry Laurenzo writes:
> > After spending a week in the morass of this, I have to say that I am less
> > certain than I was on any front regarding the text/binary distinction.
> I'll
> > take some time and benchmark different cases. My hypothe
Greg Stark writes:
> On Tue, Oct 19, 2010 at 3:45 PM, Tom Lane wrote:
>> Relcache entries alone are not gonna work. There is way too much stuff
>> that assumes that tables are correctly represented in the system
>> catalogs.
> Well we're talking about multiple things now. In the global temporar
On Tue, Oct 19, 2010 at 4:12 PM, Tom Lane wrote:
> ... and relpages and reltuples ...
Those are hardly very convincing examples. Neither are values that
need to be updated in transactions and neither relates to the
definition of the table. They could be moved from pg_class to some
internal data s
1 - 100 of 133 matches
Mail list logo
