On 04/30/2014 01:27 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Josh Berkus j...@agliodbs.com writes:
... so let's stop using that phrase, OK?
http://meyerweb.com/eric/comment/chech.html
Shrug ... what I see there is a rant from a guy with no sense of humor.
+1
On Mon, Mar 3, 2014 at 8:12 AM, Robert Haas robertmh...@gmail.com wrote:
As a GSoC student, I will implement WAL recovery of hash indexes using the
other index types' WAL code as a guide.
Frankly, I'm skeptical of the idea that hash indexes will ever really
be useful. I realize that that's a
On 04/30/2014 07:39 AM, Amit Kapila wrote:
On Wed, Apr 30, 2014 at 3:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
This looks correct to me. popen() requires SYSTEMQUOTEs on Windows, like
system() does.
It seems right now SYSTEMQUOTE is used
(2014/04/28 23:31), Robert Haas wrote:
On Thu, Apr 24, 2014 at 7:59 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
The patch attached improves docs in fdwhandler.sgml a little bit.
When you submit a patch, it's helpful to describe what the patch
actually does, rather than just saying it
I committed the non-invasive fixes to backbranches (and master too, just
to keep it in sync), but the attached is what I came up with for master.
There are a couple of places in the code where we have #ifdef WIN32 code
that uses CreateProcess with CMD /C ... directly. I believe those are
On 04/29/2014 06:00 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 04/29/2014 02:56 AM, Heikki Linnakangas wrote:
On 04/28/2014 10:32 PM, Tom Lane wrote:
Meh. I still think it's a bad idea to have CATALOG_VERSION_NO getting
compiled into libpgcommon.a, where there will be
On 04/30/2014 02:35 AM, Heikki Linnakangas wrote:
On 04/30/2014 01:27 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Josh Berkus j...@agliodbs.com writes:
... so let's stop using that phrase, OK?
http://meyerweb.com/eric/comment/chech.html
Shrug ... what I see there is a
On Wed, Apr 30, 2014 at 12:26:20AM -0700, Peter Geoghegan wrote:
On Mon, Mar 3, 2014 at 8:12 AM, Robert Haas robertmh...@gmail.com wrote:
As a GSoC student, I will implement WAL recovery of hash indexes using the
other index types' WAL code as a guide.
Frankly, I'm skeptical of the idea
On 04/30/2014 02:53 PM, Andrew Dunstan wrote:
On 04/30/2014 02:35 AM, Heikki Linnakangas wrote:
On 04/30/2014 01:27 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Josh Berkus j...@agliodbs.com writes:
... so let's stop using that phrase, OK?
The table of contents for pg_restore -l shows the time the archive was
made as local time (it uses ctime()):
; Archive created at Wed Apr 30 10:03:28 2014
Is this clear enough that it is local time? Should we display this
better, perhaps with a time zone designation?
--
Bruce
hi,
I need to use the hook feature of planner in postgresql 9.3 to perform a
task. I am building postgresql from source.
To start with, I wanted to know how to create a hook and attach that shared
libray to postgresql. Hence i tried the examples given in
Hi,
Coverity flagged a couple of issues that seem to worth addressing by
changing the code instead of ignoring them:
01) heap_xlog_update() looks to coverity as if it could trigger a NULL
pointer dereference. That's because it thinks that oldtup.t_data is
NULL if XLR_BKP_BLOCK(0) while
On 2014-04-30 17:39:27 +0200, Andres Freund wrote:
Hi,
Coverity flagged a couple of issues that seem to worth addressing by
changing the code instead of ignoring them:
01) heap_xlog_update() looks to coverity as if it could trigger a NULL
pointer dereference. That's because it thinks
On 04/30/2014 06:31 AM, Heikki Linnakangas wrote:
Andrew: you have a cygwin installation, don't you? Could you test if
pg_ctl start works when the binaries are installed to a path that
contains both a space and an @ sign, like C:\white
space\at@sign\install. I suspect it doesn't, but the
On 2014-04-04 16:44:46 +0200, Andres Freund wrote:
On 2014-02-27 21:44:48 -0500, Peter Eisentraut wrote:
+open HBA, $tempdir/pgdata/pg_hba.conf;
+print HBA local replication all trust\n;
+print HBA host replication all 127.0.0.1/32 trust\n;
+print HBA host replication all ::1/128 trust\n;
On 2014-04-30 18:09:15 +0200, Andres Freund wrote:
The issues here don't seem to have been addressed in the commit. At
least the latin1 thing should be fixed.
As an additional issue it currently doesn't seem to work in VPATH
builds. That's imo a must fix.
Greetings,
Andres Freund
--
Hello.There is a task "Sequential disk access during VACUUM for GiST/GIN " in list GSOC14.Nobody is working on this task?Do I understand this task correctly?I must recode gistbulkdelete.GistBDItem *stack is must have items with sequential blkno as possible.I have a question:where are access to
On Wed, Apr 30, 2014 at 5:55 AM, k...@rice.edu k...@rice.edu wrote:
I do not think that CPU costs matter as much as the O(1) probe to
get a result value specifically for very large indexes/tables where
even caching the upper levels of a B-tree index would kill your
working set in memory. I
On Wed, Apr 30, 2014 at 12:54 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Apr 30, 2014 at 5:55 AM, k...@rice.edu k...@rice.edu wrote:
I do not think that CPU costs matter as much as the O(1) probe to
get a result value specifically for very large indexes/tables where
even caching the
I wrote:
I'm still dubious about halving the step distance, because there are
assorted places that adjust the indentation of specific keywords by
distances that aren't a multiple of 2 (look for odd last arguments to
appendContextKeyword). I'm not sure how that will look after we make such
a
Robert Haas robertmh...@gmail.com writes:
I thought the theoretical advantage of hash indexes wasn't that they
were smaller but that you avoided a central contention point (the
btree root).
Of course our current hash indexes have *more* not less contention
than btree but I'm pretty
On Wed, Apr 30, 2014 at 10:11 AM, Robert Haas robertmh...@gmail.com wrote:
I thought the theoretical advantage of hash indexes wasn't that they
were smaller but that you avoided a central contention point (the
btree root).
The B-Tree root isn't really a central contention point at all. The
On Wed, Apr 30, 2014 at 11:01 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It might lead to good things later; and even if
it doesn't, the lack of WAL support is an embarrassment.
I don't think it will, but I do agree that the current state of
affairs is an embarrassment.
--
Peter Geoghegan
--
On Wed, Apr 30, 2014 at 12:26 AM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Mar 3, 2014 at 8:12 AM, Robert Haas robertmh...@gmail.com wrote:
As a GSoC student, I will implement WAL recovery of hash indexes using
the
other index types' WAL code as a guide.
Frankly, I'm skeptical of
All,
(dropping pgsql-advocacy off the cc list)
On 04/30/2014 10:11 AM, Robert Haas wrote:
On Wed, Apr 30, 2014 at 12:54 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Apr 30, 2014 at 5:55 AM, k...@rice.edu k...@rice.edu wrote:
I do not think that CPU costs matter as much as the O(1) probe
On Wed, Apr 30, 2014 at 11:02 AM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Apr 30, 2014 at 10:11 AM, Robert Haas robertmh...@gmail.com
wrote:
I thought the theoretical advantage of hash indexes wasn't that they
were smaller but that you avoided a central contention point (the
btree
On 2014-04-30 11:10:22 -0700, Jeff Janes wrote:
I've seen the simple pinning and unpinning of the root page (or the fast root,
whatever the first page we bother to pin on a regular basis is called) be a
point of contention. When one index dominates the entire system workload,
that
one page
On Wed, Apr 30, 2014 at 2:02 PM, Peter Geoghegan p...@heroku.com wrote:
Of course our current hash indexes have *more* not less contention
than btree but I'm pretty comfortable chalking that up to quality of
implementation rather than anything intrinsic.
I am not convinced of that.
In commit
Heikki Linnakangas hlinnakan...@vmware.com writes:
I committed the non-invasive fixes to backbranches (and master too, just
to keep it in sync), but the attached is what I came up with for master.
The malloc's in the new system.c file should be pg_malloc, or else have
custom defenses against
On Wed, Apr 30, 2014 at 11:03 AM, Jeff Janes jeff.ja...@gmail.com wrote:
If we don't put in the work to make them useful, then they won't ever become
useful.
If we do put in the effort (and it would be considerable) then I think they
will be. But you may be correct that the effort required
On 04/30/2014 11:58 AM, Andrew Dunstan wrote:
On 04/30/2014 06:31 AM, Heikki Linnakangas wrote:
Andrew: you have a cygwin installation, don't you? Could you test if
pg_ctl start works when the binaries are installed to a path that
contains both a space and an @ sign, like C:\white
I think the key question was if someone wanted to develop a good hash
index would they start from our current hash index or would they be
better off starting from a fresh codebase? If the former then we
should add WAL logging and throw GSOC and other people who ask for
projects at it. If the
On Wed, Apr 30, 2014 at 6:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I pushed a patch that does it that way, and also patches for the other
items discussed in this thread.
Great! thanks a lot. This makes a really solid noticeable difference
even in relatively simple cases and I know of users for
* Greg Stark (st...@mit.edu) wrote:
But imnsho doing nothing is a bad idea. We should have long ago either
added WAL logging or removed the index type. We shouldn't have left a
foot-gun that large lying around for so long.
I certainly encourage you to work on it. :)
Incidentally something
On Wed, Apr 30, 2014 at 11:19 AM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Apr 30, 2014 at 11:03 AM, Jeff Janes jeff.ja...@gmail.com wrote:
If we don't put in the work to make them useful, then they won't ever
become
useful.
If we do put in the effort (and it would be
On Wed, Apr 30, 2014 at 12:16 PM, Greg Stark st...@mit.edu wrote:
I think the key question was if someone wanted to develop a good hash
index would they start from our current hash index or would they be
better off starting from a fresh codebase?
If it were me I'd start with the current
On 01/05/14 02:51, Bruce Momjian wrote:
The table of contents for pg_restore -l shows the time the archive was
made as local time (it uses ctime()):
; Archive created at Wed Apr 30 10:03:28 2014
Is this clear enough that it is local time? Should we display this
better, perhaps with a
Is there a good reason for this thread being copied to the advocacy list? It
seems to me just on topic for hackers. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Stephen Frost wrote:
* Greg Stark (st...@mit.edu) wrote:
I could do the legwork on either the GUC or moving hash indexes to an
extension if there's a consensus. But I suspect either will be quite
controversial...
If you'd like to build an extension which provides hash indexes- I say
go
On Mon, Apr 28, 2014 at 4:19 PM, Petr Jelinek p...@2ndquadrant.com wrote:
On 28/04/14 16:27, Robert Haas wrote:
On Thu, Apr 24, 2014 at 1:39 AM, Craig Ringer cr...@2ndquadrant.com
wrote:
On 04/17/2014 08:35 AM, Craig Ringer wrote:
I've just noticed that the bgworker control interfaces do not
I wrote:
How about we change common/relpath.[hc] to export a single version of
relpath() that takes its arguments as separate plain OIDs, and then
make the other versions wrappers that are only declared in some
backend header? The wrappers could possibly be macros, allowing
things like
On 04/30/2014 03:03 PM, Andrew Dunstan wrote:
On 04/30/2014 11:58 AM, Andrew Dunstan wrote:
On 04/30/2014 06:31 AM, Heikki Linnakangas wrote:
Andrew: you have a cygwin installation, don't you? Could you test if
pg_ctl start works when the binaries are installed to a path that
contains
Greg Stark st...@mit.edu writes:
But imnsho doing nothing is a bad idea. We should have long ago either
added WAL logging or removed the index type. We shouldn't have left a
foot-gun that large lying around for so long.
We can't remove the hash index type, nor move it to an extension,
because
On Mon, Apr 28, 2014 at 4:24 PM, Petr Jelinek p...@2ndquadrant.com wrote:
Yes, the patch fixes it for me.
OK. I committed it. Thanks for the report.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list
Andres Freund and...@2ndquadrant.com writes:
On 2014-04-28 13:20:47 -0400, Tom Lane wrote:
Printing anything other than the relation OID here is irrelevant,
misleading, and inconsistent with our practice everywhere else.
I don't think it's really comparable to the other scenarios. We should
On Thu, May 1, 2014 at 08:27:49AM +1200, Gavin Flower wrote:
On 01/05/14 02:51, Bruce Momjian wrote:
The table of contents for pg_restore -l shows the time the archive was
made as local time (it uses ctime()):
; Archive created at Wed Apr 30 10:03:28 2014
Is this clear enough that
On 01/05/14 12:04, Bruce Momjian wrote:
On Thu, May 1, 2014 at 08:27:49AM +1200, Gavin Flower wrote:
On 01/05/14 02:51, Bruce Momjian wrote:
The table of contents for pg_restore -l shows the time the archive was
made as local time (it uses ctime()):
; Archive created at Wed Apr 30
On Tue, Apr 29, 2014 at 5:39 AM, Thomas Reiss thomas.re...@dalibo.com wrote:
You can find attached a small patch to fix the pg_replication_slots
documentation. The slot_type and plugin are not in the appropriate
order, slot_name and plugin have a wrong type and xmin appears two times.
Without
On Thu, May 1, 2014 at 12:33 AM, Rajmohan C csrajmo...@gmail.com wrote:
I need to use the hook feature of planner in postgresql 9.3 to perform a
task. I am building postgresql from source.
This hook is called planner_hook_type and is present in planner.c.
To start with, I wanted to know how
On Wed, Apr 30, 2014 at 4:01 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I committed the non-invasive fixes to backbranches (and master too, just to
keep it in sync), but the attached is what I came up with for master.
There are a couple of places in the code where we have #ifdef
Hi
I tried to start writing a patch to add Total Size column to \dt++ output.
in src/bin/psql/describe.c we have this
listTables(
const char *tabtypes,
const char *pattern,
bool verbose,
bool showSystem)
I was (as a long time Pg user) dead sure that psql really sometimes
cares about the
51 matches
Mail list logo
