Simon Riggs wrote:
Preventing work on new indexes by non-committers has meant that Bitmap
indexes, which first came out in 2005 have not been usable with
Postgres. That forced people *away* from Postgres towards Bizgres. Lack
of Bitmap indexes is a huge issue for many people. It's 2009 now and
On Wed, 21 Jan 2009, Bruce Momjian wrote:
Josh Berkus wrote:
Bruce,
Plugability adds complexity. Heikki's comment is that adding this patch
make the job of creating pluggable indexes 5% easier, while no one is
actually working on plugable indexes, and it hard to say that making it
5% easier
Hi all,
I hope to raise some valid concerns with the following two stories, a true
story first then a little fiction that I hope has a lot to do with current
reality.
Le jeudi 22 janvier 2009, Heikki Linnakangas a écrit :
It's also impossible to do many other things without modifying the
On Thu, 2009-01-22 at 10:09 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Preventing work on new indexes by non-committers has meant that Bitmap
indexes, which first came out in 2005 have not been usable with
Postgres. That forced people *away* from Postgres towards Bizgres. Lack
Oleg Bartunov wrote:
as I understand, there are already plans to utilize this feature. If so,
we need to be more attentive by now.
Is there? If I understood Simon correctly in the last paragraphs of
these emails:
On Thu, 2009-01-22 at 14:52 +0200, Heikki Linnakangas wrote:
Oleg Bartunov wrote:
as I understand, there are already plans to utilize this feature. If so,
we need to be more attentive by now.
Is there? If I understood Simon correctly in the last paragraphs of
these emails:
Simon Riggs wrote:
Immediate use cases for me would be
* ability to filter WAL records based on database or relation
This patch isn't enough to allow the catalog lookups. Without the
catalog lookups, you might as well implement that as an external tool,
like pglesslog.
* ability to
On Thu, 2009-01-22 at 16:15 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Immediate use cases for me would be
* ability to filter WAL records based on database or relation
This patch isn't enough to allow the catalog lookups. Without the
catalog lookups, you might as well
On Thu, Jan 22, 2009 at 9:15 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Immediate use cases for me would be
* ability to filter WAL records based on database or relation
This patch isn't enough to allow the catalog lookups. Without the catalog
lookups, you might as
Robert Haas wrote:
The fact the patch does not do anything that anyone might ever want is
not a sufficient grounds for rejecting it.
Huh? That sounds like enough of a reason to me.
Much ink has been spilled in this space over the size and difficulty
of reviewing Simon's hot standby patch, on
Robert Haas escribió:
We allow extensibility and hooks in other parts of the database where
the use case is pretty thin and tenuous. I betcha there aren't many
people who try writing their own eqjoinsel() either.
The PostGIS guys do implement their own selectivity estimators. In fact
it was
Simon Riggs wrote:
On Thu, 2009-01-22 at 16:15 +0200, Heikki Linnakangas wrote:
That might be useful. But again, could just as well be implemented as an
external tool like pglesslog.
There is no WAL record for no-op, at least not one of variable length.
Hmm, maybe there should be? That
On Thu, Jan 22, 2009 at 10:31 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The fact the patch does not do anything that anyone might ever want is
not a sufficient grounds for rejecting it.
Huh? That sounds like enough of a reason to me.
s/anything that anyone might ever
Robert Haas wrote:
On Thu, Jan 22, 2009 at 10:31 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The fact the patch does not do anything that anyone might ever want is
not a sufficient grounds for rejecting it.
Huh? That sounds like enough of a reason to me.
s/anything that
On Thu, Jan 22, 2009 at 11:13 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
On Thu, 2009-01-22 at 16:15 +0200, Heikki Linnakangas wrote:
That might be useful. But again, could just as well be implemented as an
external tool like pglesslog.
There is no
On Thu, 2009-01-22 at 18:13 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2009-01-22 at 16:15 +0200, Heikki Linnakangas wrote:
That might be useful. But again, could just as well be implemented as an
external tool like pglesslog.
There is no WAL record for no-op, at
All,
I have a suggestion for the rmgr patch.
Currently, there are *no* plans to get WAL working for the new hash
indexes, nor is there time.
I suggest that we take the rmgr patch and combine it with getting WAL
working properly for Bitmap-on-disk and Hash indexes in 8.5. Having
this patch
On Thu, 2009-01-22 at 13:45 +, Simon Riggs wrote:
But this isn't just for me...
I have an old proposal here:
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00404.php
Of course, the number one problem I ran into was that I never actually
wrote the code, not that I needed it to be a
On Thu, 2009-01-22 at 11:23 -0800, Josh Berkus wrote:
I suggest that we take the rmgr patch and combine it with getting WAL
working properly for Bitmap-on-disk and Hash indexes in 8.5. Having
this patch attached to an actual implementation will show if it's the
correct code to make
On Wed, 2009-01-21 at 18:38 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
So you *must* replay catalog entries and recreate the original catalog
in exact synchronisation with reading WAL files. Recreating the catalog
can only be done by Postgres itself.
The startup process doesn't
Simon,
Your suggestion sounds reasonable and I thank you, but doesn't actually
address the plugin discussion at all. It had absolutely zip to do with
making building indexes easier; it was about enabling robust index
plugins, period. (As well as other worthwhile use cases). It's not a
cost
Needless
to say if you're both waiting for each other nothing will get done.
SET deadlock_timeout = '3d';
;-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, 2009-01-21 at 14:05 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Latest version of rmgr hooks patch for later review in current
commitfest.
I'd like to reject this patch.
...
The external indexam use case doesn't impress me either, and Tom seems to
agree
The external indexam use case doesn't impress me either, and Tom seems to agree
(http://archives.postgresql.org/message-id/24006.1221483...@sss.pgh.pa.us).
Just for correctness - there is one external index
http://www.cs.purdue.edu/spgist/
--
Teodor Sigaev
On Wed, 2009-01-21 at 14:05 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Latest version of rmgr hooks patch for later review in current
commitfest.
I'd like to reject this patch.
...
I've read through all the related threads again, and I just still don't
see a convincing use
Simon Riggs wrote:
Latest version of rmgr hooks patch for later review in current
commitfest.
I'd like to reject this patch.
I've read through all the related threads again, and I just still don't
see a convincing use case for it. I think that tools that let you
introspect and modify WAL
On Wed, 2009-01-21 at 16:25 +0300, Teodor Sigaev wrote:
The external indexam use case doesn't impress me either, and Tom seems to
agree
(http://archives.postgresql.org/message-id/24006.1221483...@sss.pgh.pa.us).
Just for correctness - there is one external index
On Wed, Jan 21, 2009 at 1:25 PM, Simon Riggs si...@2ndquadrant.com wrote:
The only reasonable way to examine the contents of WAL files is with
reference to a copy of the catalog that wrote them, timed *exactly* in
synchronisation with the WAL stream.
This is a good point.
Regarding the
On Wed, 2009-01-21 at 14:28 +, Greg Stark wrote:
The only advantage that remains, I think, is the real-world concern
that you can have proprietary plugins
How exactly is this plugin more likely to result in a proprietary plugin
than all of the other plugin types we have? Because I
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2009-01-21 at 14:28 +, Greg Stark wrote:
The only advantage that remains, I think, is the real-world concern
that you can have proprietary plugins
** I have no plans for selling software that has been enabled by this
patch. **
Hm, I
Simon Riggs wrote:
Right now we've got a variety of index types that are *not* flourishing
(hash, bitmap, grouped).
Hash indexam has been in core for ages, and yet no-one has bothered to
implement WAL logging. If I've understood correctly, it has been now
been revamped in 8.4 so that there's
On Wed, 2009-01-21 at 16:07 +, Gregory Stark wrote:
The plugin approach was suggested because it brings together so many
use cases in one and adds missing robustness to a case where we
already have extensibility. Extensibility is about doing things for
specific implementations
Simon Riggs wrote:
So you *must* replay catalog entries and recreate the original catalog
in exact synchronisation with reading WAL files. Recreating the catalog
can only be done by Postgres itself.
The startup process doesn't have a relcache, so this rmgr patch is
nowhere near enough to
Heikki Linnakangas wrote:
Simon Riggs wrote:
Right now we've got a variety of index types that are *not* flourishing
(hash, bitmap, grouped).
Hash indexam has been in core for ages, and yet no-one has bothered to
implement WAL logging. If I've understood correctly, it has been now
been
Simon Riggs wrote:
Why do we have 12+ pluggable languages, but we're not allowed to write
pluggable indexes? Whatever argument you put against it being too hard
or dangerous or whatever *also* applies to languages. Yet experience
shows pluggability has resulted in a variety of robust and useful
On Wed, 2009-01-21 at 18:24 +0200, Heikki Linnakangas wrote:
If we allow them to develop as separate projects, then whenever they
are ready they can be used with particular releases.
Developing a new indexam is not something you do over the weekend.
It's a long way from design to an
On Wed, 2009-01-21 at 18:38 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
So you *must* replay catalog entries and recreate the original catalog
in exact synchronisation with reading WAL files. Recreating the catalog
can only be done by Postgres itself.
The startup process doesn't
On Wed, 2009-01-21 at 19:13 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Why do we have 12+ pluggable languages, but we're not allowed to write
pluggable indexes? Whatever argument you put against it being too hard
or dangerous or whatever *also* applies to languages. Yet experience
On Wed, 2009-01-21 at 19:13 +0200, Heikki Linnakangas wrote:
You don't want pluggable indexes, don't use 'em. But that isn't an
argument against allowing the capability for others. That line of
thought would have led us to banning pluggable languages. We should
respect the roots of this
All,
I really don't see why we would object to making *anything* pluggable if
someone was willing to write the code to do so. For example, making
storage pluggable would allow PostgreSQL to achieve great new things on
new types of hardware. (yes, I have some idea how difficult this would be)
Josh Berkus wrote:
All,
I really don't see why we would object to making *anything* pluggable if
someone was willing to write the code to do so. For example, making
storage pluggable would allow PostgreSQL to achieve great new things on
new types of hardware. (yes, I have some idea how
Bruce,
Plugability adds complexity. Heikki's comment is that adding this patch
make the job of creating pluggable indexes 5% easier, while no one is
actually working on plugable indexes, and it hard to say that making it
5% easier really advances anything, especially since many of our
existing
Josh Berkus wrote:
Bruce,
Plugability adds complexity. Heikki's comment is that adding this patch
make the job of creating pluggable indexes 5% easier, while no one is
actually working on plugable indexes, and it hard to say that making it
5% easier really advances anything, especially
Bruce Momjian br...@momjian.us wrote:
It is cost vs. benefit. No one is saying plugabiity is bad, only
that
in this case it is more costly than beneficial
Just curious -- are we talking execution time costs or programming
costs because of increased code complexity?
-Kevin
--
Sent via
Kevin Grittner wrote:
Bruce Momjian br...@momjian.us wrote:
It is cost vs. benefit. No one is saying plugabiity is bad, only
that
in this case it is more costly than beneficial
Just curious -- are we talking execution time costs or programming
costs because of increased code
On Wed, 2009-01-21 at 18:06 -0500, Bruce Momjian wrote:
Plugability adds complexity. Heikki's comment is that adding this
patch make the job of creating pluggable indexes 5% easier, while no
one is actually working on plugable indexes, and it hard to say that
making it 5% easier really
Simon Riggs wrote:
On Wed, 2009-01-21 at 18:06 -0500, Bruce Momjian wrote:
Plugability adds complexity. Heikki's comment is that adding this
patch make the job of creating pluggable indexes 5% easier, while no
one is actually working on plugable indexes, and it hard to say that
making
On Wed, 2009-01-21 at 17:46 -0600, Kevin Grittner wrote:
Bruce Momjian br...@momjian.us wrote:
It is cost vs. benefit. No one is saying plugabiity is bad, only
that
in this case it is more costly than beneficial
Just curious -- are we talking execution time costs or programming
costs
On Wed, 2009-01-21 at 17:49 +, Simon Riggs wrote:
On Wed, 2009-01-21 at 18:24 +0200, Heikki Linnakangas wrote:
Bruce Lindsay, IBM Fellow and long term DB guru was interviewed in 2005:
Q: If you magically had enough extra time to do one additional thing at
work that you're not doing now,
I am curious. I read this whole current thread. What is wrong with the
patch? As I understand it it does not increase complexity. It appears to
only expose (or perhaps abstract?) existing functionality into a usable
API that is not dependent on something being in core.
Imagine if at some
Simon Riggs wrote:
Without the patch it is completely *impossible* to write an index plugin
that is *recoverable*.
It's also impossible to do many other things without modifying the
source code. Bitmap indexam had to do it, my clustered indexes had to do
it, GIN had to do it.
Yes, we have
On Thu, 2008-12-18 at 14:30 +0900, ITAGAKI Takahiro wrote:
Simon Riggs si...@2ndquadrant.com wrote:
Latest version of rmgr hooks patch for later review in current
commitfest.
(Minor update to CVS HEAD).
It doesn't work on Window (EXEC_BACKEND platform) because
Wow, you are really shooting out a lot of good stuff today!
---
Simon Riggs wrote:
Latest version of rmgr hooks patch for later review in current
commitfest.
(Minor update to CVS HEAD).
--
Simon Riggs
Latest version of rmgr hooks patch for later review in current
commitfest.
(Minor update to CVS HEAD).
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: src/backend/access/transam/rmgr.c
Simon Riggs si...@2ndquadrant.com wrote:
Latest version of rmgr hooks patch for later review in current
commitfest.
(Minor update to CVS HEAD).
It doesn't work on Window (EXEC_BACKEND platform) because
shared_preload_libraries are not loaded in startup process.
So, there are no timing to
55 matches
Mail list logo
