On Tue, 2007-04-10 at 12:18 -0700, Gurjeet Singh wrote:
> Also, although the whole plan-tree is available in
> get_relation_info(), but it wouldn't be the right place to scan other
> tables, for eg., for generating JOIN-INDEXes or materializing some
> intermediate joins. (sometime in the futur
On 4/12/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Gurjeet Singh wrote:
> The interface etc. may not be beautiful, but it isn't ugly either!
It is
> a lot better than manually creating pg_index records and inserting them
into
> cache; we use index_create() API to create the index (build is
Gurjeet Singh wrote:
> The interface etc. may not be beautiful, but it isn't ugly either! It is
> a lot better than manually creating pg_index records and inserting them into
> cache; we use index_create() API to create the index (build is deferred),
> and then 'rollback to savepoint' to undo t
Hi Tom,
The original patch was submitted by Kai Sattler, and we (at EDB) spent a
lot of time improving it, making it as seamless and as user-friendly as
possible. As is evident from the version number of the patch (v26), it has
gone through a lot of iterations, and was available to the communi
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> Please find attached the latest version of the patch. It applies cleanly on
> REL8_2_STABLE.
The interface to the planner in this seems rather brute-force. To run
a plan involving a hypothetical index, you have to make a bunch of
catalog entries, run
I need someone to review this patch to make sure the API used is
logical. You can do that by reading the README file in the patch. To
me, the procedure seems overly complicated, and too restrictive.
The patch is in the patches queue.
On 1/8/07, Tom Lane <[EMAIL PROTECTED]> wrote:
(This is not a statement that I approve of the specific plugin hooks
proposed --- I don't particularly. But if we can come up with something
a bit cleaner, that's how I'd approach it.)
I have another idea for making the hooks a bit more cleaner;
On Mon, 2007-01-08 at 12:16 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Mon, 2007-01-08 at 11:28 -0500, Bruce Momjian wrote:
> >> The complex part of this is that the feature requires patches to the
> >> backend, and has a /contrib component.
>
> > The plugin approach
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Mon, 2007-01-08 at 11:28 -0500, Bruce Momjian wrote:
>> The complex part of this is that the feature requires patches to the
>> backend, and has a /contrib component.
> The plugin approach is exactly what happened with the debugger. The
> backend has
On Mon, 2007-01-08 at 11:28 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Sat, 2007-01-06 at 16:08 -0500, Bruce Momjian wrote:
> >
> > > I have looked over this patch, and it completes part of this TODO item:
> > >
> > > o Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM
Simon Riggs wrote:
> On Sat, 2007-01-06 at 16:08 -0500, Bruce Momjian wrote:
>
> > I have looked over this patch, and it completes part of this TODO item:
> >
> > o Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
> > ANALYZE, and CLUSTER
>
> > It involves a pat
One problem with only putting this information in the system logs
is that when we provide database services to a member of our
community we do not actually give them an account of the DB server
or log server. This means that this very useful information would
need to be passed through an intermedia
On 1/7/07, Gurjeet Singh <[EMAIL PROTECTED]> wrote:
contrib/pg_advise_index/sample_error_messages.txt also shows an
interesting usage, where advise_index is actually a VIEW with a RULE that
redirects INSERTs into another advise_index_data table.
Also, the DDL for the advise_index table can be
On 1/7/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
I have looked over this patch,
Thanks
I think we have to decide if we want this, and whether it should be in
/contrib or fully integrated into the backend.
Well, as already said, the plugin architecture gives others a way to develop
an
On Sat, 2007-01-06 at 16:08 -0500, Bruce Momjian wrote:
> I have looked over this patch, and it completes part of this TODO item:
>
> o Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
> ANALYZE, and CLUSTER
> It involves a patch to the backend, and a /contrib m
Kenneth Marshall wrote:
> One problem with only putting this information in the system logs
> is that when we provide database services to a member of our
> community we do not actually give them an account of the DB server
> or log server. This means that this very useful information would
> need
I have looked over this patch, and it completes part of this TODO item:
o Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM
ANALYZE, and CLUSTER
Here is the foundation of it:
For an incoming EXPLAIN command, the planner generates the plan and, if
17 matches
Mail list logo
