On Thursday, March 07, 2013 10:54 AM Greg Smith wrote:
> On 3/5/13 9:07 AM, Amit Kapila wrote:
> > In v11 patch, I have changed name of directory to config.
> > For file name, currently I have not changed, but if you feel it needs
> to be
> > changed, kindly suggest any one of above or if any other
On 3/7/13 12:15 AM, Daniel Farina wrote:
I have only done some cursory research, but cpu-time of 20% seem to
expected for InnoDB's CRC computation[0]. Although a galling number,
this comparison with other systems may be a way to see how much of
that overhead is avoidable or just the price of ent
On 3/5/13 9:07 AM, Amit Kapila wrote:
In v11 patch, I have changed name of directory to config.
For file name, currently I have not changed, but if you feel it needs to be
changed, kindly suggest any one of above or if any other better you have in
mind.
This seems fine for now. Hashing out exa
On Wed, Mar 6, 2013 at 8:17 PM, Greg Smith wrote:
> TL;DR summary: on a system I thought was a fair middle of the road server,
> pgbench tests are averaging about a 2% increase in WAL writes and a 2%
> slowdown when I turn on checksums. There are a small number of troublesome
> cases where that
TL;DR summary: on a system I thought was a fair middle of the road
server, pgbench tests are averaging about a 2% increase in WAL writes
and a 2% slowdown when I turn on checksums. There are a small number of
troublesome cases where that overhead rises to closer to 20%, an upper
limit that's
On Wed, Mar 6, 2013 at 11:04 PM, Robert Haas wrote:
>> When we first talked about this feature for
>> 9.2, we were going to exclude hint bits from checksums, in order to
>> avoid this issue; what happened to that?
>
> I don't think anyone ever thought that was a particularly practical
> design. I
On 3/6/13 1:24 PM, Tom Lane wrote:
Andres Freund writes:
On 2013-03-06 11:21:21 -0500, Garick Hamlin wrote:
If picking a CRC why not a short optimal one rather than truncate CRC32C?
CRC32C is available in hardware since SSE4.2.
I think that should be at most a fourth-order consideration,
On 3/6/13 6:34 AM, Heikki Linnakangas wrote:
Another thought is that perhaps something like CRC32C would be faster to
calculate on modern hardware, and could be safely truncated to 16-bits
using the same technique you're using to truncate the Fletcher's
Checksum. Greg's tests showed that the over
On Sun, Jan 27, 2013 at 1:55 AM, Kohei KaiGai wrote:
> The part-2 patch adds new OAT_POST_ALTER event type, and
> its relevant permission checks on contrib/sepgsql.
This documentation hunk is unclear:
+On , install permission
+will be checked if leakproof attribute was given, not only
+
On 2/2/13 3:23 AM, Pavel Stehule wrote:
Hello
I propose enhancing GET DIAGNOSTICS statement about new field
PG_CONTEXT. It is similar to GET STACKED DIAGNOSTICS'
PG_EXCEPTION_CONTEXT.
Motivation for this proposal is possibility to get call stack for
debugging without raising exception.
This c
On 2/2/13 4:05 AM, Paul Norman wrote:
Hello,
After a discussion on IRC in #postgresql, I had a feature suggestion and it
was suggested I write it up here.
I have a large (200GB, 1.7b rows) table with a number of columns, but the
two of interest here are a hstore column, tags and a postgis geomet
On 3/6/13 1:14 PM, Josh Berkus wrote:
There may be good reasons to reject this patch. Or there may not.
But I completely disagree with the idea that asking them to solve the
problem at the filesystem level is sensible.
Yes, can we get back to the main issues with the patch?
1) argument over
On 3/4/13 7:04 PM, Daniel Farina wrote:
Corruption has easily occupied more than one person-month of time last
year for us.
Just FYI for anyone that's experienced corruption... we've looked into doing
row-level checksums at work. The only challenge we ran into was how to check
them when readi
On Sun, Jan 27, 2013 at 1:55 AM, Kohei KaiGai wrote:
> The part-1 patch adds catalog/objectaccess.c to have entrypoints of
> object_access_hook, instead of simple macro definition, to simplify
> invocations with arguments. It is just a replacement of existing
> OAT_POST_CREATE and OAT_DROP invocat
On Wed, Feb 27, 2013 at 8:58 AM, Stephen Frost wrote:
> * Boszormenyi Zoltan (z...@cybertec.at) wrote:
>> But unlike statement_timeout,
>> with lock_timeout_stmt the statement can still finish after this limit
>> as it does useful work besides waiting for locks.
>
> It's still entirely possible to
On Thu, Mar 7, 2013 at 9:48 AM, Michael Paquier
wrote:
>
>
> On Thu, Mar 7, 2013 at 7:19 AM, Andres Freund wrote:
>
>> On 2013-03-07 05:26:31 +0900, Michael Paquier wrote:
>> > On Thu, Mar 7, 2013 at 2:34 AM, Fujii Masao
>> wrote:
>> >
>> > > On Thu, Mar 7, 2013 at 2:17 AM, Andres Freund > >
>> >
On 03/07/2013 08:41 AM, Andres Freund wrote:
> On 2013-03-07 08:37:40 +0800, Craig Ringer wrote:
>> On 03/06/2013 07:34 PM, Heikki Linnakangas wrote:
>>> It'd be difficult to change the algorithm in a future release without
>>> breaking on-disk compatibility,
>> On-disk compatibility is broken with
On Thu, Mar 7, 2013 at 7:19 AM, Andres Freund wrote:
> On 2013-03-07 05:26:31 +0900, Michael Paquier wrote:
> > On Thu, Mar 7, 2013 at 2:34 AM, Fujii Masao
> wrote:
> >
> > > On Thu, Mar 7, 2013 at 2:17 AM, Andres Freund
> > > wrote:
> > > >> Indexes:
> > > >> "hoge_pkey" PRIMARY KEY, btree
On 3/6/13 1:34 PM, Robert Haas wrote:
We've had a few EnterpriseDB customers who have had fantastically
painful experiences with PostgreSQL + ZFS. Supposedly, aligning the
ZFS block size to the PostgreSQL block size is supposed to make these
problems go away, but in my experience it does not hav
On 2013-03-07 08:37:40 +0800, Craig Ringer wrote:
> On 03/06/2013 07:34 PM, Heikki Linnakangas wrote:
> > It'd be difficult to change the algorithm in a future release without
> > breaking on-disk compatibility,
> On-disk compatibility is broken with major releases anyway, so I don't
> see this as
On 03/06/2013 07:34 PM, Heikki Linnakangas wrote:
> It'd be difficult to change the algorithm in a future release without
> breaking on-disk compatibility,
On-disk compatibility is broken with major releases anyway, so I don't
see this as a huge barrier.
--
Craig Ringer http://
I found this sentence somewhat confusing:
"It is possible for a column's value to change even when the trigger
is not fired,"
http://www.postgresql.org/docs/devel/static/sql-createtrigger.html#SQL-CREATETRIGGER-NOTES
More precise would be something along the lines "It is possible that
changes to
Fujii Masao wrote:
> On Tue, Mar 5, 2013 at 7:36 AM, Kevin Grittner wrote:
>> Fujii Masao wrote:
>>
>>> When I accessed the materialized view in the standby server,
>>
>>> I got the following ERROR message. Looks odd to me. Is this a bug?
>>>
>>> ERROR: materialized view "hogeview" has not
Andres Freund writes:
> On 2013-03-06 11:21:21 -0500, Garick Hamlin wrote:
>> If picking a CRC why not a short optimal one rather than truncate CRC32C?
> CRC32C is available in hardware since SSE4.2.
I think that should be at most a fourth-order consideration, since we
are not interested solely
On 03/06/2013 03:06 PM, Robert Haas wrote:
On Wed, Mar 6, 2013 at 6:00 PM, Josh Berkus wrote:
We've had a few EnterpriseDB customers who have had fantastically
painful experiences with PostgreSQL + ZFS. Supposedly, aligning the
ZFS block size to the PostgreSQL block size is supposed to make
On Wed, Mar 6, 2013 at 6:00 PM, Josh Berkus wrote:
>> We've had a few EnterpriseDB customers who have had fantastically
>> painful experiences with PostgreSQL + ZFS. Supposedly, aligning the
>> ZFS block size to the PostgreSQL block size is supposed to make these
>> problems go away, but in my ex
On Wed, Mar 6, 2013 at 2:14 PM, Josh Berkus wrote:
> Based on Smith's report, I consider (2) to be a deal-killer right now.
I was pretty depressed by those numbers, too.
> The level of overhead reported by him would prevent the users I work
> with from ever employing checksums on production syst
Robert,
> We've had a few EnterpriseDB customers who have had fantastically
> painful experiences with PostgreSQL + ZFS. Supposedly, aligning the
> ZFS block size to the PostgreSQL block size is supposed to make these
> problems go away, but in my experience it does not have that effect.
> So I t
> Kevin Grittner wrote:
>> Tatsuo Ishii wrote:
>>
>>> Was the remaining work on docs done? I would like to test MVs and
>>> am waiting for the docs completed.
>>
>> I think they are done. If you notice anything missing or in need
>> of clarification please let me know. At this point missing doc
On Mar 6, 2013, at 1:51 PM, Kevin Grittner wrote:
> I also think that something should be done about the documentation
> for indexes. Right now that always refers to a "table". It would
> clearly be awkward to change that to "table or materialized view"
> everywhere. I wonder if most of thosse
On 2013-03-07 05:26:31 +0900, Michael Paquier wrote:
> On Thu, Mar 7, 2013 at 2:34 AM, Fujii Masao wrote:
>
> > On Thu, Mar 7, 2013 at 2:17 AM, Andres Freund
> > wrote:
> > >> Indexes:
> > >> "hoge_pkey" PRIMARY KEY, btree (i)
> > >> "hoge_pkey_cct" PRIMARY KEY, btree (i) INVALID
> > >>
Kevin Grittner wrote:
> Tatsuo Ishii wrote:
>
>> Was the remaining work on docs done? I would like to test MVs and
>> am waiting for the docs completed.
>
> I think they are done. If you notice anything missing or in need
> of clarification please let me know. At this point missing docs
> would
On 2013-03-07 02:34:54 +0900, Fujii Masao wrote:
> On Thu, Mar 7, 2013 at 2:17 AM, Andres Freund wrote:
> >> Indexes:
> >> "hoge_pkey" PRIMARY KEY, btree (i)
> >> "hoge_pkey_cct" PRIMARY KEY, btree (i) INVALID
> >> "hoge_pkey_cct1" PRIMARY KEY, btree (i) INVALID
> >> "hoge_pkey_cct
Michael Meskes wrote:
> On Mon, Mar 04, 2013 at 05:08:26PM -0300, Alvaro Herrera wrote:
> > Another point worth considering is that most of this is duplicated by
> > ecpg's libpgtypes. Do we want to fix that one too, or do we just let it
> > continue to be broken? I note that other bugs are alrea
On Mon, Mar 04, 2013 at 05:55:26PM -0300, Alvaro Herrera wrote:
> error codes for the caller to figure out. Maybe we could create a layer
> on top of ereport, that gets both the error message, sqlstate etc, and
> ...
Couldn't we just create ecpg's own version of ereport, that does "the right
thing
On Mon, Mar 04, 2013 at 05:08:26PM -0300, Alvaro Herrera wrote:
> Another point worth considering is that most of this is duplicated by
> ecpg's libpgtypes. Do we want to fix that one too, or do we just let it
> continue to be broken? I note that other bugs are already unfixed in
> ecpg's copy.
On Thu, Mar 7, 2013 at 2:09 AM, Fujii Masao wrote:
> On Wed, Mar 6, 2013 at 8:59 PM, Michael Paquier
> wrote:
> > OK. Patches updated... Please see attached.
>
> I found odd behavior. After I made REINDEX CONCURRENTLY fail twice,
> I found that the index which was not marked as INVALID remained
> There may be good reasons to reject this patch. Or there may not.
> But I completely disagree with the idea that asking them to solve the
> problem at the filesystem level is sensible.
Yes, can we get back to the main issues with the patch?
1) argument over whether the checksum is sufficient
2013-03-06 19:53 keltezéssel, Tom Lane írta:
Robert Haas writes:
On Wed, Feb 27, 2013 at 8:58 AM, Stephen Frost wrote:
It's still entirely possible to get 99% done and then hit that last
tuple that you need a lock on and just tip over the lock_timeout_stmt
limit due to prior waiting and endin
Robert Haas writes:
> On Wed, Feb 27, 2013 at 8:58 AM, Stephen Frost wrote:
>> It's still entirely possible to get 99% done and then hit that last
>> tuple that you need a lock on and just tip over the lock_timeout_stmt
>> limit due to prior waiting and ending up wasting a bunch of work, hence
>>
On Mon, Mar 4, 2013 at 3:13 PM, Heikki Linnakangas
wrote:
> On 04.03.2013 20:58, Greg Smith wrote:
>>
>> There
>> is no such thing as a stable release of btrfs, and no timetable for when
>> there will be one. I could do some benchmarks of that but I didn't think
>> they were very relevant. Who car
On 2013-03-06 09:53:29 -0800, Josh Berkus wrote:
> Peter,
>
> > At run time, this will sort itself out, because all the required modules
> > will be loaded. The problem is when you create the "glue" extension and
> > haven't invoked any code from any of the dependent extension in the
> > session.
On 2013-03-06 11:31:06 -0600, Merlin Moncure wrote:
> On Wed, Mar 6, 2013 at 10:53 AM, Andres Freund wrote:
> > On 2013-03-06 09:36:19 -0600, Merlin Moncure wrote:
> >> On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland wrote:
> >> > On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
> >> > wrote:
Peter,
> At run time, this will sort itself out, because all the required modules
> will be loaded. The problem is when you create the "glue" extension and
> haven't invoked any code from any of the dependent extension in the
> session.
Just invoking code doesn't seem to be enough. I tried ju
Kohei KaiGai writes:
> 2013/3/6 Tom Lane :
>> I think if we're going to support magic row identifiers, they need to
>> be actual system columns, complete with negative attnums and entries
>> in pg_attribute.
> Sorry, -1 for me.
> The proposed design tried to kill two birds with one stone.
> The
On Thu, Mar 7, 2013 at 2:17 AM, Andres Freund wrote:
>> Indexes:
>> "hoge_pkey" PRIMARY KEY, btree (i)
>> "hoge_pkey_cct" PRIMARY KEY, btree (i) INVALID
>> "hoge_pkey_cct1" PRIMARY KEY, btree (i) INVALID
>> "hoge_pkey_cct_cct" PRIMARY KEY, btree (i)
>
> Huh, why did that go through
On Wed, Mar 6, 2013 at 10:53 AM, Andres Freund wrote:
> On 2013-03-06 09:36:19 -0600, Merlin Moncure wrote:
>> On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland wrote:
>> > On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
>> > wrote:
>> >> With these tweaks, I was able to make pglz-based delta e
On 3/5/13 5:52 PM, Josh Berkus wrote:
> More on this: the problem appears to be that the symbols for hstore are
> loaded only if I've just just created the extension in that database:
I see. This is a problem with any kind of dynamically loadable module
that uses another module. The other module
On 2013-03-07 02:09:49 +0900, Fujii Masao wrote:
> On Wed, Mar 6, 2013 at 8:59 PM, Michael Paquier
> wrote:
> > OK. Patches updated... Please see attached.
>
> I found odd behavior. After I made REINDEX CONCURRENTLY fail twice,
> I found that the index which was not marked as INVALID remained une
On 2013-03-06 09:08:10 -0800, Jeff Janes wrote:
> On Wed, Mar 6, 2013 at 8:53 AM, Andres Freund wrote:
>
> > On 2013-03-06 09:36:19 -0600, Merlin Moncure wrote:
> > > On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland wrote:
> > > > On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
> > > > wrote:
On Wed, Mar 6, 2013 at 8:59 PM, Michael Paquier
wrote:
> OK. Patches updated... Please see attached.
I found odd behavior. After I made REINDEX CONCURRENTLY fail twice,
I found that the index which was not marked as INVALID remained unexpectedly.
=# CREATE TABLE hoge (i int primary key);
CREATE
On Wed, Mar 6, 2013 at 8:53 AM, Andres Freund wrote:
> On 2013-03-06 09:36:19 -0600, Merlin Moncure wrote:
> > On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland wrote:
> > > On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
> > > wrote:
> > >> With these tweaks, I was able to make pglz-based delt
Shigeru Hanada writes:
> I'm not sure whether postgres_fdw should support, but updatable views
> have no system column including ctid. So, we need magic identifier,
> perhaps it would be set of primary key value(s), to support updating
> remote updatable views via foreign tables.
Yeah, I conside
On 2013-03-06 11:21:21 -0500, Garick Hamlin wrote:
> If picking a CRC why not a short optimal one rather than truncate CRC32C?
CRC32C is available in hardware since SSE4.2.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On 2013-03-06 09:36:19 -0600, Merlin Moncure wrote:
> On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland wrote:
> > On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
> > wrote:
> >> With these tweaks, I was able to make pglz-based delta encoding perform
> >> roughly as well as Amit's patch.
> >
> >
On Wed, Mar 06, 2013 at 01:34:21PM +0200, Heikki Linnakangas wrote:
> On 06.03.2013 10:41, Simon Riggs wrote:
>> On 5 March 2013 18:02, Jeff Davis wrote:
>>
>>> Fletcher is probably significantly faster than CRC-16, because I'm just
>>> doing int32 addition in a tight loop.
>>>
>>> Simon originall
On Tue, Mar 5, 2013 at 9:08 PM, Robert Haas wrote:
> All that having been said, it's hard for me to imagine that anyone
> really cares about any of this until we have an incremental update
> feature, which right now we don't. Actually, I'm betting that's going
> to be significantly harder than au
Kevin,
I haven't seen a reply to this. Were you able to give my notes below
any consideration?
On 2/15/13 12:44 PM, Peter Eisentraut wrote:
> On 1/25/13 1:00 AM, Kevin Grittner wrote:
>> New patch rebased, fixes issues raised by Thom Brown, and addresses
>> some of your points.
>
> This patch
Bernd Helmle wrote:
> Looking into this issue, it seems the version check in getTables() of
> pg_dump.c
> is wrong. Shouldn't the check be
>
> if (fout->remoteVersion >= 90300)
> {
>
> }
>
> since this is where pg_relation_is_scannable() is introduced?
Fixed.
Thanks for the report!
--
Kevin G
On Wed, Mar 6, 2013 at 8:32 AM, Joachim Wieland wrote:
> On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
> wrote:
>> With these tweaks, I was able to make pglz-based delta encoding perform
>> roughly as well as Amit's patch.
>
> Out of curiosity, do we know how pglz compares with other algorit
Bernd Helmle wrote:
> It looks like the recent matview patch broke pg_dump in a way, which make it
> impossible to dump 9.1 and 9.2 databases.
>
> it fails with
>
> pg_dump: [Archivierer (DB)] query failed: ERROR: function
> pg_relation_is_scannable(oid) does not exist
>
> Looking into this issu
Tatsuo Ishii wrote:
> Was the remaining work on docs done? I would like to test MVs and
> am waiting for the docs completed.
I think they are done. If you notice anything missing or in need
of clarification please let me know. At this point missing docs
would be a bug in need of a fix.
--
Kev
On 2013-03-06 13:34:21 +0200, Heikki Linnakangas wrote:
> On 06.03.2013 10:41, Simon Riggs wrote:
> >On 5 March 2013 18:02, Jeff Davis wrote:
> >
> >>Fletcher is probably significantly faster than CRC-16, because I'm just
> >>doing int32 addition in a tight loop.
> >>
> >>Simon originally chose Fl
On Tue, Mar 5, 2013 at 8:32 AM, Heikki Linnakangas
wrote:
> With these tweaks, I was able to make pglz-based delta encoding perform
> roughly as well as Amit's patch.
Out of curiosity, do we know how pglz compares with other algorithms, e.g. lz4 ?
--
Sent via pgsql-hackers mailing list (pgsql-
On 03/05/2013 07:23 PM, Tom Lane wrote:
Maciek Sakrejda writes:
Thank you: I think this is what I was missing, and what wasn't clear
from the proposed doc patch. But then how can pg_dump assume that it's
always safe to set extra_float_digits = 3?
It's been proven (don't have a link handy, but
Simon Riggs writes:
> On 5 March 2013 22:02, Tom Lane wrote:
>> FWIW, my opinion is that doing anything like this in the planner is
>> going to be enormously expensive.
> As we already said: no MVs => zero overhead => no problem.
Well, in the first place that statement is false on its face: we'
On 06.03.2013 10:41, Simon Riggs wrote:
On 5 March 2013 18:02, Jeff Davis wrote:
Fletcher is probably significantly faster than CRC-16, because I'm just
doing int32 addition in a tight loop.
Simon originally chose Fletcher, so perhaps he has more to say.
IIRC the research showed Fletcher wa
* Alexander Korotkov (aekorot...@gmail.com) wrote:
> Now, we probably don't have enough of time before 9.3 to solve an API
> problem :(. It's likely we have to choose either commit to 9.3 without
> clean API factorization or postpone it to 9.4.
As much as I'd like this to get in, I don't think the
On 2013-03-06 21:19:57 +0900, Michael Paquier wrote:
> On Wed, Mar 6, 2013 at 9:09 PM, Andres Freund wrote:
>
> > On 2013-03-06 20:59:37 +0900, Michael Paquier wrote:
> > > OK. Patches updated... Please see attached.
> > > With all the work done on those patches, I suppose this is close to being
>
On Wed, Mar 6, 2013 at 9:09 PM, Andres Freund wrote:
> On 2013-03-06 20:59:37 +0900, Michael Paquier wrote:
> > OK. Patches updated... Please see attached.
> > With all the work done on those patches, I suppose this is close to being
> > something clean...
>
> Yes, its looking good. There are load
On 2013-03-06 20:59:37 +0900, Michael Paquier wrote:
> OK. Patches updated... Please see attached.
> With all the work done on those patches, I suppose this is close to being
> something clean...
Yes, its looking good. There are loads of improvements possible but
those can very well be made increm
On Wed, Mar 6, 2013 at 9:30 AM, Tom Lane wrote:
> For postgres_fdw, that would really be enough, since it could just
> cause a "ctid" column to be created with the usual definition. Then
> it could put the remote ctid into the usual t_self field in returned
> tuples.
I'm not sure whether postgre
On 06-Mar-2013, at 4:12 PM, Shigeru Hanada wrote:
> On Wed, Mar 6, 2013 at 12:35 PM, Pavan Deolasee
> wrote:
>> In the context of postgres_fdw, I am not sure if we need an additional
>> system column like a node_id. Would there be a possibility where
>> tuples to-be-modified are coming from di
On Wednesday, March 06, 2013 2:57 AM Heikki Linnakangas wrote:
> On 04.03.2013 06:39, Amit Kapila wrote:
> > On Sunday, March 03, 2013 8:19 PM Craig Ringer wrote:
> >> On 02/05/2013 11:53 PM, Amit Kapila wrote:
> Performance data for the patch is attached with this mail.
> Conclusions fro
It looks like the recent matview patch broke pg_dump in a way, which make
it impossible to dump 9.1 and 9.2 databases.
it fails with
pg_dump: [Archivierer (DB)] query failed: ERROR: function
pg_relation_is_scannable(oid) does not exist
Looking into this issue, it seems the version check in
On Wed, Mar 6, 2013 at 12:35 PM, Pavan Deolasee
wrote:
> In the context of postgres_fdw, I am not sure if we need an additional
> system column like a node_id. Would there be a possibility where
> tuples to-be-modified are coming from different foreign tables and at
> runtime we need to decide whe
Maciek Sakrejda wrote:
> On Tue, Mar 5, 2013 at 12:03 AM, Albe Laurenz wrote:
>> I don't think that it is about looking nice.
>> C doesn't promise you more than FLT_DIG or DBL_DIG digits of
>> precision, so PostgreSQL cannot either.
>>
>> If you allow more, that would mean that if you store the sa
On 2013-03-05 19:30:53 -0500, Tom Lane wrote:
> One of the core problems for a writable-foreign-tables feature is how
> to identify a previously-fetched row for UPDATE or DELETE actions.
> In an ordinary Postgres table, we use the ctid system column for that,
> but a remote table doesn't necessaril
On Wed, Jan 23, 2013 at 7:29 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 23.01.2013 09:36, Alexander Korotkov wrote:
> >> On Wed, Jan 23, 2013 at 6:08 AM, Tom Lane wrote:
> >>> The biggest problem is that I really don't care for the idea of
> >>> contrib/pg_trgm being this cozy with
On 2013-03-06 13:21:27 +0900, Michael Paquier wrote:
> Please find attached updated patch realigned with your comments. You can
> find my answers inline...
> The only thing that needs clarification is the comment about
> UNIQUE_CHECK_YES/UNIQUE_CHECK_NO. Except that all the other things are
> corre
On 5 March 2013 18:02, Jeff Davis wrote:
> Fletcher is probably significantly faster than CRC-16, because I'm just
> doing int32 addition in a tight loop.
>
> Simon originally chose Fletcher, so perhaps he has more to say.
IIRC the research showed Fletcher was significantly faster for only a
sma
On 5 March 2013 09:35, Heikki Linnakangas wrote:
>> Are there objectors?
>
>
> In addition to my hostility towards this patch in general, there are some
> specifics in the patch I'd like to raise (read out in a grumpy voice):
;-) We all want to make the right choice here, so all viewpoints
grat
On 5 March 2013 22:02, Tom Lane wrote:
> FWIW, my opinion is that doing anything like this in the planner is
> going to be enormously expensive. Index matching is already pretty
> expensive, and that has the saving grace that we only do it once per
> base relation. Your sketch above implies try
On 05.03.2013 14:09, KONDO Mitsumasa wrote:
Hi,
Horiguch's patch does not seem to record minRecoveryPoint in ReadRecord();
Attempt patch records minRecoveryPoint.
[crash recovery -> record minRecoveryPoint in control file -> archive
recovery]
I think that this is an original intention of Heikki'
84 matches
Mail list logo
