Hi all,
Just a curiosity I couldnt control. I was recently reading about
Fractal tree indexing
(http://www.tokutek.com/2012/12/fractal-tree-indexing-overview/) and
how TokuDB engine for MySQL is really working nicely with big data.
I was wondering, do we have support for fractal tree indexing? I
On 13.02.2013 09:46, Kyotaro HORIGUCHI wrote:
In this case, the FINAL consistency point is at the
XLOG_SMGR_TRUNCATE record, but current implemet does not record
the consistency point (checkpoint, or commit or smgr_truncate)
itself, so we cannot predict the final consistency point on
starting of
This patch against PostgreSQL 9.1.8 takes advantage of efficient file
cloning on Linux Btrfs file systems to make CREATE DATABASE operations
extremely fast regardless of the size of the database used as a
template. On my system, I can create a database from a multi-gibibyte
template in a second or
On 13.02.2013 11:01, Atri Sharma wrote:
Hi all,
Just a curiosity I couldnt control. I was recently reading about
Fractal tree indexing
(http://www.tokutek.com/2012/12/fractal-tree-indexing-overview/) and
how TokuDB engine for MySQL is really working nicely with big data.
Hmm, sounds very
On Wed, Feb 13, 2013 at 3:08 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 13.02.2013 11:01, Atri Sharma wrote:
Hi all,
Just a curiosity I couldnt control. I was recently reading about
Fractal tree indexing
(http://www.tokutek.com/2012/12/fractal-tree-indexing-overview/) and
how
On Wed, Feb 13, 2013 at 1:38 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 13.02.2013 11:01, Atri Sharma wrote:
Hi all,
Just a curiosity I couldnt control. I was recently reading about
Fractal tree indexing
Wed:
I remember we have already discussed fractal trees privately. Short
conclusions are so:
1) Fractal tree indexes are patented. It is distributed as commercial
extension to MySQL. So we can't include it into PostgreSQL core.
2) Tokutek can't provide full-fledged fractal tree indexes as
On Wed, Feb 13, 2013 at 10:19 AM, Atri Sharma atri.j...@gmail.com wrote:
2) Tokutek can't provide full-fledged fractal tree indexes as PostgreSQL
extension because lack of WAL extensibility.
We could think about WAL extensibility which would help other applications
as well.
Sounds nice. WAL
On Tuesday, February 12, 2013 9:02 PM Andres Freund wrote:
On 2013-02-12 20:19:43 +0530, Amit Kapila wrote:
On Tuesday, February 12, 2013 4:55 PM Andres Freund wrote:
On 2013-02-12 14:57:51 +0530, Amit Kapila wrote:
On Tuesday, February 12, 2013 11:24 AM Boszormenyi Zoltan wrote:
Sent from my iPad
On 13-Feb-2013, at 18:21, Greg Stark st...@mit.edu wrote
Heikki was talking about a generic WAL record type that would just
store a binary delta between the version of the block when it was
locked and when it was unlocked. That would handle any extension
cleanly as far
On 04.01.2013 10:42, Alexander Korotkov wrote:
/*
* Calculate selectivity of operator using histograms of range lower bounds
* and histogram of range lengths.
*/
static double
calc_hist_selectivity_overlap(TypeCacheEntry *typcache, RangeBound *lower,
On Wed, Feb 13, 2013 at 4:51 PM, Greg Stark st...@mit.edu wrote:
Heikki was talking about a generic WAL record type that would just
store a binary delta between the version of the block when it was
locked and when it was unlocked. That would handle any extension
cleanly as far as data
On 13.02.2013 15:31, Alexander Korotkov wrote:
On Wed, Feb 13, 2013 at 4:51 PM, Greg Starkst...@mit.edu wrote:
Heikki was talking about a generic WAL record type that would just
store a binary delta between the version of the block when it was
locked and when it was unlocked. That would
Sent from my iPad
On 13-Feb-2013, at 19:05, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 13.02.2013 15:31, Alexander Korotkov wrote:
On Wed, Feb 13, 2013 at 4:51 PM, Greg Starkst...@mit.edu wrote:
Heikki was talking about a generic WAL record type that would just
store a binary
On Wed, Feb 13, 2013 at 5:28 PM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 04.01.2013 10:42, Alexander Korotkov wrote:
/*
* Calculate selectivity of operator using histograms of range lower
bounds
* and histogram of range lengths.
*/
static double
On 13 February 2013 13:35, Heikki Linnakangas hlinnakan...@vmware.com wrote:
You could have a generic WAL record that applies changes to multiple pages
atomically.
I think its a good idea, the best idea even, but we still have no idea
what the requirements are without a clear case for an
Sent from my iPad
On 13-Feb-2013, at 19:31, Simon Riggs si...@2ndquadrant.com wrote:
.
I think its a good idea, the best idea even, but we still have no idea
what the requirements are without a clear case for an external index.
It could easily turn out that we invent a plausible API that's
On 02/13/2013 09:13 AM, Atri Sharma wrote:
Sent from my iPad
On 13-Feb-2013, at 19:31, Simon Riggs si...@2ndquadrant.com wrote:
.
I think its a good idea, the best idea even, but we still have no idea
what the requirements are without a clear case for an external index.
It could easily turn
If they are patented as Alexander says upthread, then surely the idea is dead
in the water.
True, I think so too.
But,the generic WAL seems an awesome idea and I would love to help.
Atri
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 02/13/2013 10:43 PM, Andrew Dunstan wrote:
On 02/13/2013 09:13 AM, Atri Sharma wrote:
Sent from my iPad
On 13-Feb-2013, at 19:31, Simon Riggs si...@2ndquadrant.com wrote:
.
I think its a good idea, the best idea even, but we still have no idea
what the requirements are without a clear
Atri Sharma atri.j...@gmail.com writes:
Do you think building a new index in postgres with fractal trees as
the basis would serve the purpose? or is there something else we
should think of?
First explain why you couldn't build it as an opclass for gist or
spgist ...
Heikki Linnakangas hlinnakan...@vmware.com writes:
At least in back-branches, I'd call this a pilot error. You can't turn a
master into a standby just by creating a recovery.conf file. At least
not if the master was not shut down cleanly first.
...
I'm not sure that's worth the trouble,
Here's an updated version of pg_xlogdump. This is rebased on top of the
committed xlogreader, palloc restructuring and libpgcommon, PG_RMGR
stuff, and is basically a revamped version of what Andres submitted in
the other problem I mentioned up-thread, with %s
for NULL values:
SELECT format('|%s|', NULL);
Result: ||
SELECT format('|%5s|', NULL);
Result: ||
In the second case, I think it should produce | |.
fixed
Regards
Pavel Stehule
Regards,
Dean
format-width-20130213.patch
Description
Sorry for my late updates.
I tried to update list of permissions that sepgsql expects, even though
the description might be still a bit rough...
https://wiki.postgresql.org/wiki/SEPostgreSQL_Permissions
Set of permissions are defined for each object class that represents
a particular
Forgive the top-reply.
After reading the discussion, I'm in favor of the philosophically
correct approach rather than the usually-technically-correct approach.
That is, display the warning, but let the sysadmin/dba do what they
need/want to do and trust that, most of the time, they know what
Sent from my iPad
On 13-Feb-2013, at 20:30, Tom Lane t...@sss.pgh.pa.us wrote:
First explain why you couldn't build it as an opclass for gist or
spgist ...
That needs thinking about a bit.I was confused about the current indexes
because they all build on BTrees.But,
On Tue, Feb 12, 2013 at 1:18 PM, David E. Wheeler da...@justatheory.com wrote:
couple other suggestions:
Existing Name Proposed Name
--
json_array_length() array_length() or length() or size()
On 2013-02-13 12:09:37 -0300, Alvaro Herrera wrote:
Here's an updated version of pg_xlogdump. This is rebased on top of the
committed xlogreader, palloc restructuring and libpgcommon, PG_RMGR
stuff, and is basically a revamped version of what Andres submitted in
On 03.02.2013 08:24, Pavan Deolasee wrote:
On Sun, Feb 3, 2013 at 2:31 AM, Jeff Janesjeff.ja...@gmail.com wrote:
I've attached a patch with these changes made. Does this look OK?
Looks good to me. I also repeated pgbench and make check and they work
as expected. I'll add it to the CF and
On 13.02.2013 17:49, Atri Sharma wrote:
On 13-Feb-2013, at 20:30, Tom Lanet...@sss.pgh.pa.us wrote:
First explain why you couldn't build it as an opclass for gist or
spgist ...
That needs thinking about a bit.I was confused about the current indexes
because they all build on BTrees.But,
On 2/12/13 7:19 AM, Andres Freund wrote:
On 2013-02-12 12:14:06 +, Peter Eisentraut wrote:
Add noreturn attributes to some error reporting functions
I wonder if its time to add a macro for this instead of slapping
__attribute__((noreturn)) everywhere. That way msvc had a chance of
Sent from my iPad
.
That makes no sense. I don't see any way to implement this in an opclass, and
it wouldn't make sense to re-implement this for every opclass anyway.
The basic idea of a fractal tree index is to attach a buffer to every
non-leaf page. On insertion, instead of
Heikki Linnakangas hlinnakan...@vmware.com writes:
The basic idea of a fractal tree index is to attach a buffer to every
non-leaf page. On insertion, instead of descending all the way down to
the correct leaf page, the new tuple is put on the buffer at the root
page. When that buffer fills
On 02/12/2013 02:18 PM, David E. Wheeler wrote:
Hello Hackers,
If you dislike bike-shedding (and who does?), delete this email and the ensuing
thread right now. You have been warned!
I have been playing with Andrew’s JSON enhancements and really enjoying them. I
am already using them in
On 02/13/2013 11:20 AM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
The basic idea of a fractal tree index is to attach a buffer to every
non-leaf page. On insertion, instead of descending all the way down to
the correct leaf page, the new tuple is put on the buffer at
On 13.02.2013 18:20, Tom Lane wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
The basic idea of a fractal tree index is to attach a buffer to every
non-leaf page. On insertion, instead of descending all the way down to
the correct leaf page, the new tuple is put on the buffer at the
On 13.02.2013 18:43, Andrew Dunstan wrote:
On 02/13/2013 11:20 AM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
The basic idea of a fractal tree index is to attach a buffer to every
non-leaf page. On insertion, instead of descending all the way down to
the correct leaf
Yeah,it is just a fancy name for something that has nothing to do with
fractals.I guess everything suave these days is fractal!
That said,the buffered concept itself looks really cool and should help us in
large data sets.I am eager to get off the mark with it.
Will we be building the index
Andrew Dunstan and...@dunslane.net writes:
I will take some of this under advisement. Note that
json_populate_record's name was taken from hstore's populate_record, so
if we're trying to use similar names then it should possibly be just
populate_record. Or if that's still a bit long I would
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan and...@dunslane.net wrote:
I don't have any problem getting rid of the json_ prefixes, except for
json_agg which I think should keep it (c.f. string_agg, array_agg).
I think that's an unfortunately naming forced on us by the SQL standard, and it
On 2/11/13 1:35 PM, Heikki Linnakangas wrote:
I agree it's pretty dumb that there's currently no such escape. I think JDBC
inherited that design mistake from ODBC. Fixing that would be a good idea.
Lance Anderson, Oracle's JDBC spec lead, says [1] we can implement
something like:
Since we already do escape processing much like c that might not be so
complex. However I haven't looked at the code, so I could be way off base.
The question I would pose is how palatable is it to use ? In other words is
it worth pursuing ?
Dave Cramer
dave.cramer(at)credativ(dot)ca
2013/2/13 David E. Wheeler da...@justatheory.com:
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan and...@dunslane.net wrote:
I don't have any problem getting rid of the json_ prefixes, except for
json_agg which I think should keep it (c.f. string_agg, array_agg).
I think that's an unfortunately
On 02/13/2013 12:07 PM, David E. Wheeler wrote:
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan and...@dunslane.net wrote:
I don't have any problem getting rid of the json_ prefixes, except for json_agg
which I think should keep it (c.f. string_agg, array_agg).
I think that's an unfortunately
Sent from my iPad
On 13-Feb-2013, at 22:21, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 13.02.2013 18:43, Andrew Dunstan wrote:
On 02/13/2013 11:20 AM, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
The basic fractal indexes is what I've read on some
On Feb 13, 2013, at 9:31 AM, Andrew Dunstan and...@dunslane.net wrote:
I don’t love those, but if we want to follow precedent…
Ditto. I think we're a bit late to be adding functionality.
Well, how about having just keys() and vals() return arrays? Then one can just
wrap them in unnest() to
Andrew Dunstan wrote:
On 02/13/2013 12:07 PM, David E. Wheeler wrote:
On Feb 13, 2013, at 8:36 AM, Andrew Dunstan and...@dunslane.net wrote:
I think Merlin's suggestion if unwrap might be good. Or simply elements()
might work.
Perhaps unwrap() returns a set and elements() returns an
Seamus Abshere escribió:
[1]
http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2013-February/58.html
[2]
http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2013-February/date.html#51
(threaded view gets it out of order)
Ooh, how archaic --- they're still using Mhonarc to
On 13 February 2013 16:48, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 13.02.2013 18:20, Tom Lane wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
The basic idea of a fractal tree index is to attach a buffer to every
non-leaf page. On insertion, instead of descending all
On 02/13/2013 09:54 AM, Simon Riggs wrote:
I'd call it out as a marketing name. I guess it's fractal in the sense that
all levels of the tree can hold leaf tuples in the buffers; the structure
looks the same no matter how deep you zoom, like a fractal.. But Buffered
would be more appropriate
On 13 February 2013 09:04, Heikki Linnakangas hlinnakan...@vmware.com wrote:
To be precise, we'd need to update the control file on every XLogFlush(),
like we do during archive recovery. That would indeed be unacceptable from a
performance point of view. Updating the control file that often
On 02/13/2013 01:01 AM, Atri Sharma wrote:
Hi all,
Just a curiosity I couldnt control. I was recently reading about
Fractal tree indexing
(http://www.tokutek.com/2012/12/fractal-tree-indexing-overview/) and
how TokuDB engine for MySQL is really working nicely with big data.
I was
Simon Riggs si...@2ndquadrant.com writes:
On 13 February 2013 09:04, Heikki Linnakangas hlinnakan...@vmware.com wrote:
To be precise, we'd need to update the control file on every XLogFlush(),
like we do during archive recovery. That would indeed be unacceptable from a
performance point of
On 13.02.2013 20:25, Simon Riggs wrote:
On 13 February 2013 09:04, Heikki Linnakangashlinnakan...@vmware.com wrote:
To be precise, we'd need to update the control file on every XLogFlush(),
like we do during archive recovery. That would indeed be unacceptable from a
performance point of view.
Heikki Linnakangas hlinnakan...@vmware.com writes:
Well, no-one's complained about the performance. From a robustness point
of view, it might be good to keep the minRecoveryPoint value in a
separate file, for example, to avoid rewriting the control file that
often. Then again, why fix it
On 13.02.2013 21:21, Tom Lane wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
Well, no-one's complained about the performance. From a robustness point
of view, it might be good to keep the minRecoveryPoint value in a
separate file, for example, to avoid rewriting the control file that
On 13.02.2013 21:03, Tom Lane wrote:
Simon Riggssi...@2ndquadrant.com writes:
On 13 February 2013 09:04, Heikki Linnakangashlinnakan...@vmware.com wrote:
To be precise, we'd need to update the control file on every XLogFlush(),
like we do during archive recovery. That would indeed be
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 13.02.2013 21:21, Tom Lane wrote:
It would only be broken if someone interrupted a crash recovery
mid-flight and tried to establish a recovery stop point before the end
of WAL, no? Why don't we just forbid that case? This would either be
On 13.02.2013 21:30, Tom Lane wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
On 13.02.2013 21:21, Tom Lane wrote:
It would only be broken if someone interrupted a crash recovery
mid-flight and tried to establish a recovery stop point before the end
of WAL, no? Why don't we just
On Wed, Feb 13, 2013 at 8:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
The basic idea of a fractal tree index is to attach a buffer to every
non-leaf page. On insertion, instead of descending all the way down to
the correct leaf page, the new
Heikki Linnakangas hlinnakan...@vmware.com writes:
The problem we're trying to solve is determining how much WAL needs to
be replayed until the database is consistent again. In crash recovery,
the answer is all of it. That's why the CRC in the WAL is essential;
it's required to determine
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 13.02.2013 21:30, Tom Lane wrote:
Well, archive recovery is a different scenario --- Simon was questioning
whether we need a minRecoveryPoint mechanism in crash recovery, or at
least that's what I thought he asked.
Ah, ok. The short
Hello
probably one from my top ten SQL statement will be
SELECT * FROM some_relation LIMIT 10
what do you thinking about creating special statement for this purpose?
possible syntax
-- ViewTable
\vt table_name [rows]
or
\sample table_name [rows]
a implementation with autocomplete is
Seamus Abshere sea...@abshere.net wrote:
On 2/11/13 1:35 PM, Heikki Linnakangas wrote:
I agree it's pretty dumb that there's currently no such escape.
I think JDBC inherited that design mistake from ODBC. Fixing
that would be a good idea.
Lance Anderson, Oracle's JDBC spec lead
Wow, there's
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
SELECT * FROM some_relation LIMIT 10
what do you thinking about creating special statement for this purpose?
I'd rather extend TABLE to support a limit clause or something.
Thanks,
Stephen
signature.asc
Description:
On 13.02.2013 17:02, Tom Lane wrote:
Heikki Linnakangashlinnakan...@vmware.com writes:
At least in back-branches, I'd call this a pilot error. You can't turn a
master into a standby just by creating a recovery.conf file. At least
not if the master was not shut down cleanly first.
...
I'm not
2013/2/13 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
SELECT * FROM some_relation LIMIT 10
what do you thinking about creating special statement for this purpose?
I'd rather extend TABLE to support a limit clause or something.
??
Pavel
On 13.02.2013 22:17, Kevin Grittner wrote:
Seamus Absheresea...@abshere.net wrote:
SELECT * FROM tbl WHERE data {postgres qm} 'abc'
That suggestion makes a lot of sense to me. The curly-brace
escapes are in JDBC for portability, so this seems like a totally
appropriate use; it's
On Wed, February 13, 2013 21:23, Stephen Frost wrote:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
SELECT * FROM some_relation LIMIT 10
what do you thinking about creating special statement for this purpose?
I'd rather extend TABLE to support a limit clause or something.
No need; that
* Erik Rijkers (e...@xs4all.nl) wrote:
No need; that already does work, e.g.:
testdb=# table pg_database limit 3;
Oh.
Not in the documentation, but I hope it won't get removed -- it's quite handy
Perhaps we should add it. :)
Thanks!
Stephen
signature.asc
2013/2/13 Stephen Frost sfr...@snowman.net:
* Erik Rijkers (e...@xs4all.nl) wrote:
No need; that already does work, e.g.:
testdb=# table pg_database limit 3;
Oh.
Not in the documentation, but I hope it won't get removed -- it's quite handy
Perhaps we should add it. :)
my proposal is
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
and I expect so limit 10 is default
table statement is little bit different creature (and mainly it is server
side)
I don't really see the value in this.
Thanks,
Stephen
signature.asc
Description: Digital signature
On 13 February 2013 09:04, Heikki Linnakangas hlinnakan...@vmware.com wrote:
Without step 3, the server would perform crash recovery, and it would work.
But because of the recovery.conf file, the server goes into archive
recovery, and because minRecoveryPoint is not set, it assumes that the
2013/2/13 Stephen Frost sfr...@snowman.net:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
and I expect so limit 10 is default
table statement is little bit different creature (and mainly it is server
side)
I don't really see the value in this.
it is just shortcut for often used query -
Stephen Frost sfr...@snowman.net writes:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
SELECT * FROM some_relation LIMIT 10
what do you thinking about creating special statement for this purpose?
I'd rather extend TABLE to support a limit clause or something.
Can't you pretty much do
Here's an updated version of this patch that takes care of the issues I
reported previously: no more repalloc() of the requests array; it's now
an slist, which makes the code much more natural IMV. And no more
messing around with doing sprintf to create a separate sprintf pattern
for the per-db
Jonathan Rogers jrog...@socialserve.com writes:
This patch against PostgreSQL 9.1.8 takes advantage of efficient file
cloning on Linux Btrfs file systems to make CREATE DATABASE operations
extremely fast regardless of the size of the database used as a
template.
It would be easier to review
Tom Lane wrote:
Jonathan Rogers jrog...@socialserve.com writes:
This patch against PostgreSQL 9.1.8 takes advantage of efficient file
cloning on Linux Btrfs file systems to make CREATE DATABASE operations
extremely fast regardless of the size of the database used as a
template.
It would be
On 02/13/2013 02:13 PM, Tom Lane wrote:
The big-picture question of course is whether we want to carry and
maintain a filesystem-specific hack. I don't have a sense that btrfs
is so widely used as to justify this.
If this is a valuable hack, it seems like it could work on ZFS as well.
If we
Josh Berkus wrote:
On 02/13/2013 02:13 PM, Tom Lane wrote:
The big-picture question of course is whether we want to carry and
maintain a filesystem-specific hack. I don't have a sense that btrfs
is so widely used as to justify this.
If this is a valuable hack, it seems like it could work
On Wed, Feb 13, 2013 at 5:48 PM, Josh Berkus j...@agliodbs.com wrote:
On 02/13/2013 02:13 PM, Tom Lane wrote:
The big-picture question of course is whether we want to carry and
maintain a filesystem-specific hack. I don't have a sense that btrfs
is so widely used as to justify this.
If this
Jonathan Rogers jrog...@socialserve.com writes:
Would it be better to move clone_file() into its own module where
implementations for other file system types might eventually be added?
Yeah, possibly. I considered suggesting that the current code be
treated as a fallback implementation of
2013/2/14 Tom Lane t...@sss.pgh.pa.us:
Stephen Frost sfr...@snowman.net writes:
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
SELECT * FROM some_relation LIMIT 10
what do you thinking about creating special statement for this purpose?
I'd rather extend TABLE to support a limit clause or
Ian Lawrence Barwick barw...@gmail.com writes:
2013/2/14 Tom Lane t...@sss.pgh.pa.us:
Can't you pretty much do this already in psql with FETCH_COUNT? I see
no good reason to invent more SQL syntax.
Doesn't that just split up the retrieval of the result set into blocks of
FETCH_COUNT rows,
On Wed, Feb 13, 2013 at 6:07 PM, Pavel Stehule pavel.steh...@gmail.comwrote:
Hello
probably one from my top ten SQL statement will be
SELECT * FROM some_relation LIMIT 10
what do you thinking about creating special statement for this purpose?
possible syntax
-- ViewTable
\vt
On Wed, Feb 13, 2013 at 1:31 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
On Wed, Feb 13, 2013 at 4:51 PM, Greg Stark st...@mit.edu wrote:
Heikki was talking about a generic WAL record type that would just
store a binary delta between the version of the block when it was
locked and when
On Tue, Feb 12, 2013 at 03:22:17AM +, Greg Stark wrote:
But that said I'm not sure saying the whole file is in an encoding is
the right approach. Paths are actually binary strings. any encoding is
purely for display purposes anyways.
For Unix, yes. On Windows, they're ultimately UTF16
Shigeru Hanada shigeru.han...@gmail.com writes:
[ postgres_fdw.v5.patch ]
I started to look at this patch today. There seems to be quite a bit
left to do to make it committable. I'm willing to work on it, but
there are some things that need discussion:
* The code seems to always use
On 02/04/2013 07:40 PM, Miroslav Šimulčík wrote:
Hi Vlad,
I'm also interested in this topic and work on system-time temporal
extension. Here I wrote down design of my solution few months ago
https://wiki.postgresql.org/wiki/SQL2011Temporal. The idea is
basically the same as in your solution
You might remember this pg_upgrade bug report where the user complained
that user-defined tablespaces _inside_ the old cluster directory were
deleted by the old cluster delete script:
http://www.postgresql.org/message-id/e1thpdm-00018c...@wrigleys.postgresql.org
and my reply that we
2013/2/14 Tom Lane t...@sss.pgh.pa.us:
* deparse.c contains a depressingly large amount of duplication of logic
from ruleutils.c, and can only need more as we expand the set of
constructs that can be pushed to the remote end. This doesn't seem like
a maintainable approach. Was there a
On Wed, Feb 13, 2013 at 06:45:31AM -0800, David Fetter wrote:
On Sat, Feb 09, 2013 at 11:59:22PM -0800, David Fetter wrote:
Folks,
Per suggestions and lots of help from Andrew Gierth, please find
attached a patch to clean up the call sites for FuncCall nodes, which
I'd like to expand
Hello,
Alexander Law exclus...@gmail.com writes:
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
and the proposed patch.
With your proposed change, the problem will resurface in an actual SQL_ASCII
database. At the problem's root is
Hello
I liked this idea, but thinking better we can implement a way to users
create your own meta-commands to run:
* another meta commands (like an alias)
* SRFs
* arbitrary SQLs
All of them must accept arguments... some like this:
\mset vt :table :rows 'select * from :table limit
95 matches
Mail list logo
