Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

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 :tab

Re: [HACKERS] BUG #7493: Postmaster messages unreadable in a Windows console

Hello, Alexander Law 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 write_console()'s assumpt

Re: FILTER for aggregates [was Re: [HACKERS] Department of Redundancy Department: makeNode(FuncCall) division]

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 t

Re: [HACKERS] FDW for PostgreSQL

2013/2/14 Tom Lane : > * 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 specific reason not t

[HACKERS] pg_upgrade old cluster delete script

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 don'

Re: [HACKERS] Temporal features in PostgreSQL

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 w

Re: [HACKERS] FDW for PostgreSQL

Shigeru Hanada 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 GetOuterUserId() to select the fo

Re: [HACKERS] BUG #7493: Postmaster messages unreadable in a Windows console

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 s

Re: [HACKERS] Fractal tree indexing

On Wed, Feb 13, 2013 at 1:31 PM, Alexander Korotkov wrote: > On Wed, Feb 13, 2013 at 4:51 PM, Greg Stark 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 wo

Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

On Wed, Feb 13, 2013 at 6:07 PM, Pavel Stehule wrote: > 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] > >

Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

Ian Lawrence Barwick writes: > 2013/2/14 Tom Lane : >> 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, i.e. does not limit the result

Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

2013/2/14 Tom Lane : > Stephen Frost 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 y

Re: [HACKERS] Btrfs clone WIP patch

Jonathan Rogers 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 clone_file, but I'm not su

Re: [HACKERS] Btrfs clone WIP patch

On Wed, Feb 13, 2013 at 5:48 PM, 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 val

Re: [HACKERS] Btrfs clone WIP patch

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 coul

Re: [HACKERS] Btrfs clone WIP patch

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 w

Re: [HACKERS] Btrfs clone WIP patch

Tom Lane wrote: > Jonathan Rogers 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 re

Re: [HACKERS] Btrfs clone WIP patch

Jonathan Rogers 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 this patch if the bul

Re: PATCH: Split stats file per database WAS: [HACKERS] autovacuum stress-testing our system

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 st

Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

Stephen Frost 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 this already

Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

2013/2/13 Stephen Frost : > * 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 - nothing

Re: [HACKERS] 9.2.3 crashes during archive recovery

On 13 February 2013 09:04, Heikki Linnakangas 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 > system is consistent

Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

* 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 signat

Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

2013/2/13 Stephen Frost : > * 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 little b

Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

* 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 Desc

Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

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 ne

Re: [HACKERS] Alias hstore's ? to ~ so that it works with JDBC

On 13.02.2013 22:17, Kevin Grittner wrote: Seamus Abshere 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 surprising it hasn't com

Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

2013/2/13 Stephen Frost : > * 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 > > Thanks, > >

Re: [HACKERS] 9.2.3 crashes during archive recovery

On 13.02.2013 17:02, Tom Lane wrote: Heikki Linnakangas 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 tro

Re: [HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

* 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

Re: [HACKERS] Alias hstore's ? to ~ so that it works with JDBC

Seamus Abshere 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 a name I

[HACKERS] proposal or just idea for psql - show first N rows from relation backslash statement

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 terribl

Re: [HACKERS] 9.2.3 crashes during archive recovery

Heikki Linnakangas 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 answer to that is "no

Re: [HACKERS] 9.2.3 crashes during archive recovery

Heikki Linnakangas 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 where the WAL ends.

Re: [HACKERS] Fractal tree indexing

On Wed, Feb 13, 2013 at 8:20 AM, Tom Lane wrote: > Heikki Linnakangas 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

Re: [HACKERS] 9.2.3 crashes during archive recovery

On 13.02.2013 21:30, Tom Lane wrote: Heikki Linnakangas 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 woul

Re: [HACKERS] 9.2.3 crashes during archive recovery

Heikki Linnakangas 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 >> the same as, or

Re: [HACKERS] 9.2.3 crashes during archive recovery

On 13.02.2013 21:03, Tom Lane wrote: Simon Riggs writes: On 13 February 2013 09:04, Heikki Linnakangas 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. Updat

Re: [HACKERS] 9.2.3 crashes during archive recovery

On 13.02.2013 21:21, Tom Lane wrote: Heikki Linnakangas 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

Re: [HACKERS] 9.2.3 crashes during archive recovery

Heikki Linnakangas 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 when it's not broken.

Re: [HACKERS] 9.2.3 crashes during archive recovery

On 13.02.2013 20:25, Simon Riggs wrote: On 13 February 2013 09:04, Heikki Linnakangas 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 fi

Re: [HACKERS] 9.2.3 crashes during archive recovery

Simon Riggs writes: > On 13 February 2013 09:04, Heikki Linnakangas 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 ofte

Re: [HACKERS] Fractal tree indexing

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

Re: [HACKERS] 9.2.3 crashes during archive recovery

On 13 February 2013 09:04, Heikki Linnakangas 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 would also > be bad for

Re: [HACKERS] Alias hstore's ? to ~ so that it works with JDBC

On Feb 13, 2013 6:43 PM, "Alvaro Herrera" wrote: > > 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 o

Re: [HACKERS] Fractal tree indexing

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 appropriat

Re: [HACKERS] Fractal tree indexing

On 13 February 2013 16:48, Heikki Linnakangas wrote: > On 13.02.2013 18:20, Tom Lane wrote: >> >> Heikki Linnakangas 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 lea

Re: [HACKERS] Alias hstore's ? to ~ so that it works with JDBC

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

Re: [HACKERS] JSON Function Bike Shedding

Andrew Dunstan wrote: > > On 02/13/2013 12:07 PM, David E. Wheeler wrote: > >On Feb 13, 2013, at 8:36 AM, Andrew Dunstan 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 array? > >

Re: [HACKERS] JSON Function Bike Shedding

On Feb 13, 2013, at 9:31 AM, Andrew Dunstan 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 get sets. Best,

Re: [HACKERS] Fractal tree indexing

Sent from my iPad On 13-Feb-2013, at 22:21, Heikki Linnakangas wrote: > On 13.02.2013 18:43, Andrew Dunstan wrote: >> >> On 02/13/2013 11:20 AM, Tom Lane wrote: >>> Heikki Linnakangas writes: The basic fractal indexes is what I've read on some presentation slides on the 'net, so

Re: [HACKERS] JSON Function Bike Shedding

On 02/13/2013 12:07 PM, David E. Wheeler wrote: On Feb 13, 2013, at 8:36 AM, Andrew Dunstan 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 b

Re: [HACKERS] JSON Function Bike Shedding

2013/2/13 David E. Wheeler : > On Feb 13, 2013, at 8:36 AM, Andrew Dunstan 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 s

Re: [HACKERS] Alias hstore's ? to ~ so that it works with JDBC

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 http://www.

Re: [HACKERS] Alias hstore's ? to ~ so that it works with JDBC

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: SELECT

Re: [HACKERS] JSON Function Bike Shedding

On Feb 13, 2013, at 8:36 AM, Andrew Dunstan 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 doesn't mean we have

Re: [HACKERS] JSON Function Bike Shedding

Andrew Dunstan 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 accept to_recor

Re: [HACKERS] Fractal tree indexing

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 fr

Re: [HACKERS] Fractal tree indexing

On 13.02.2013 18:43, Andrew Dunstan wrote: On 02/13/2013 11:20 AM, Tom Lane wrote: Heikki Linnakangas 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 pu

Re: [HACKERS] Fractal tree indexing

On 13.02.2013 18:20, Tom Lane wrote: Heikki Linnakangas 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 buff

Re: [HACKERS] Fractal tree indexing

On 02/13/2013 11:20 AM, Tom Lane wrote: Heikki Linnakangas 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

Re: [HACKERS] JSON Function Bike Shedding

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 code

Re: [HACKERS] Fractal tree indexing

Heikki Linnakangas 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 up, all the tuples i

Re: [HACKERS] Fractal tree indexing

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 des

[HACKERS] Re: [COMMITTERS] pgsql: Add noreturn attributes to some error reporting functions

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 >

Re: [HACKERS] Fractal tree indexing

On 13.02.2013 17:49, Atri Sharma wrote: On 13-Feb-2013, at 20:30, Tom Lane 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, building an opclass w

Re: [HACKERS] Setting visibility map in VACUUM's second phase

On 03.02.2013 08:24, Pavan Deolasee wrote: On Sun, Feb 3, 2013 at 2:31 AM, Jeff Janes 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 also mark the patch "re

Re: [HACKERS] pg_xlogdump

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 > http://www.postgresql.org/m

Re: [HACKERS] JSON Function Bike Shedding

On Tue, Feb 12, 2013 at 1:18 PM, David E. Wheeler wrote: couple other suggestions: > Existing Name Proposed Name > -- > json_array_length() array_length() or length() or size() very much prefer wit

Re: [HACKERS] Fractal tree indexing

Sent from my iPad On 13-Feb-2013, at 20:30, Tom Lane 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, building an opclass

[HACKERS] Re: ports/174020: initdb will not run on a mounted FS with a snapshot directory

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 wha

Re: [HACKERS] [sepgsql 2/3] Add db_schema:search permission checks

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 database

Re: [HACKERS] Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used

;t look as > though you have fixed 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 |

[HACKERS] pg_xlogdump

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 http://www.postgresql.org/message-id/1357672187-7693-5-git-send-email-and...@2ndquadran

Re: [HACKERS] 9.2.3 crashes during archive recovery

Heikki Linnakangas 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, though. Perhaps it wou

Re: [HACKERS] Fractal tree indexing

Atri Sharma 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 ... regards, tom lane

Re: [HACKERS] Fractal tree indexing

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 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

Re: [HACKERS] Fractal tree indexing

> > > 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

Re: [HACKERS] Fractal tree indexing

On 02/13/2013 09:13 AM, Atri Sharma wrote: Sent from my iPad On 13-Feb-2013, at 19:31, Simon Riggs 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 p

Re: [HACKERS] Fractal tree indexing

Sent from my iPad On 13-Feb-2013, at 19:31, Simon Riggs 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 not > actually of

Re: [HACKERS] Fractal tree indexing

On 13 February 2013 13:35, Heikki Linnakangas 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 external index. It could ea

Re: [HACKERS] Statistics and selectivity estimation for ranges

On Wed, Feb 13, 2013 at 5:28 PM, Heikki Linnakangas 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 >> calc_hist_selectivity_overlap

Re: [HACKERS] Fractal tree indexing

Sent from my iPad On 13-Feb-2013, at 19:05, Heikki Linnakangas wrote: > On 13.02.2013 15:31, Alexander Korotkov wrote: >> On Wed, Feb 13, 2013 at 4:51 PM, Greg Stark wrote: >> >>> Heikki was talking about a generic WAL record type that would just >>> store a binary delta between the version

Re: [HACKERS] Fractal tree indexing

On 13.02.2013 15:31, Alexander Korotkov wrote: On Wed, Feb 13, 2013 at 4:51 PM, Greg Stark 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 extensio

Re: [HACKERS] Fractal tree indexing

On Wed, Feb 13, 2013 at 4:51 PM, Greg Stark 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 modification goes

Re: [HACKERS] Statistics and selectivity estimation for ranges

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,

Re: [HACKERS] Fractal tree indexing

Sent from my iPad On 13-Feb-2013, at 18:21, Greg Stark 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

Re: [HACKERS] Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

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

Re: [HACKERS] Fractal tree indexing

On Wed, Feb 13, 2013 at 10:19 AM, Atri Sharma 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 extensi

Re: [HACKERS] 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

Re: [HACKERS] Fractal tree indexing

On Wed, Feb 13, 2013 at 1:38 PM, Heikki Linnakangas 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/

Re: [HACKERS] Fractal tree indexing

On Wed, Feb 13, 2013 at 3:08 PM, Heikki Linnakangas 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 TokuDB e

Re: [HACKERS] Fractal tree indexing

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 simil

[HACKERS] Btrfs clone WIP patch

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

Re: [HACKERS] 9.2.3 crashes during archive recovery

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

[HACKERS] Fractal tree indexing

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