though I'd be worried about the portability price paid to have one. Or
are you concerned about whether a GUI could invoke it? I don't see why
not --- the GUIs don't reimplement pg_dump, do they?
Actually Tom, I think they do (where they have an export facility). How would
you run pg_dump on a re
Dear Tom,
I thought about it... how to solve the contradiction:
- backend vs external tool?
- new interface? new command? unix? windows?
- compatibility with old/existing interfaces?
- plugins, any one can contribute?
- don't bother DBA's
- communicate about it?
My 2 pence idea of the day
On Thursday 18 March 2004 17:51, Tom Lane wrote:
> Richard Huxton <[EMAIL PROTECTED]> writes:
> > How would you run pg_dump on a remote machine?
>
> Trivially. It's a client.
Eh? I'm assuming we're talking at cross purposes here. *I* can run it
trivially - ssh in and run it over there, or run it
Richard Huxton <[EMAIL PROTECTED]> writes:
> How would you run pg_dump on a remote machine?
Trivially. It's a client.
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Thu, 18 Mar 2004, Richard Huxton wrote:
> On Thursday 18 March 2004 10:18, Fabien COELHO wrote:
> > On Wed, 17 Mar 2004, Tom Lane wrote:
>
> > > though I'd be worried about the portability price paid to have one. Or
> > > are you concerned about whether a GUI could invoke it? I don't see why
On Thursday 18 March 2004 10:18, Fabien COELHO wrote:
> On Wed, 17 Mar 2004, Tom Lane wrote:
> > though I'd be worried about the portability price paid to have one. Or
> > are you concerned about whether a GUI could invoke it? I don't see why
> > not --- the GUIs don't reimplement pg_dump, do th
Dear Tom,
On Wed, 17 Mar 2004, Tom Lane wrote:
> If you want a GUI, it could be a GUI,
I do not want a GUI, I'm not a GUI guy;-) I was just wondering how GUI
could be adapted to deal with the tool if it is outside.
> though I'd be worried about the portability price paid to have one. Or
> are
Fabien COELHO <[EMAIL PROTECTED]> writes:
> There is something I cannot visualise about the idea being discussed.
What I'm imagining is a separate program that you run, and it connects
to the backend and grabs schema data much like pg_dump does. (In fact
the pg_dump code might possibly be useful
Dear Tom,
> I like the pg_advisor idea a lot better.
>
> [...]
>
> In the third place, if we try to solve the problem by embedding checks
> here and there in the backend, we'll limit ourselves to checks that can
> be made with minimal impact on backend performance and complexity. And
> we'll be
On Wednesday 17 March 2004 17:36, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I was thinking of a GUC variable called PERFORMANCE_HINTS, which would
> > throw a message if a lookup from the primary to the foreign key didn't
> > have an index.
>
> I like the pg_advisor idea a lot
Tom Lane <[EMAIL PROTECTED]> writes:
> BTW, something that just occurred to me now: EXPLAIN is currently really
> designed only for SELECTs. It would make sense to upgrade it for
> INSERT/UPDATE/DELETE to list the triggers that will get fired. While
> we'd have to treat user triggers as black bo
> > Also, because of the opposition by some DBA, these checks could be disable
> > by some options, but I would suggest the option to be on by default.
>
> I was thinking of a GUC variable called PERFORMANCE_HINTS, which would
> throw a message if a lookup from the primary to the foreign key didn'
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was thinking of a GUC variable called PERFORMANCE_HINTS, which would
> throw a message if a lookup from the primary to the foreign key didn't
> have an index.
I like the pg_advisor idea a lot better.
In the first place, a lot of these sorts of checks
Fabien COELHO wrote:
>
> > > Or maybe some new "ADVICE" or "ODDITY" level next to "DEBUG NOTICE
> > > WARNING ERROR PANIC...", that would be hidden by default and triggered
> > > by an option?
> >
> > But that doesn't really solve the problem, which is that there are
> > conditions that it's diffi
> > Or maybe some new "ADVICE" or "ODDITY" level next to "DEBUG NOTICE
> > WARNING ERROR PANIC...", that would be hidden by default and triggered
> > by an option?
>
> But that doesn't really solve the problem, which is that there are
> conditions that it's difficult to test for on-the-fly while a
On Mon, Mar 15, 2004 at 10:57:45AM -0800, Josh Berkus wrote:
> otherwise. I already get 2-4 warnings whenever creating a new table due to
> keys, etc. I don't read them anymore unless one of them is an ERROR, and I
> suspect that a lot of DBAs are the same.
I can second that. At least, I don
Richard, Tom:
> > > Call me crazy, but maybe we have to throw a message for primary
> > > key lookups on foreign key tables without indexes. I hate to throw a
> > > message on update/delete rather than create table, but I don't see
> > > another way.
You're crazy. For one thing, there are some
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> Maybe there should be a separate "pg_advisor" tool that you can run against a
>> database and which looks for "oddities". Something pluggable so people can
>> add tests simply.
> Or maybe some new "ADVICE" or "ODDITY" level next to "DEBUG NOTICE WARNING
On Sunday 14 March 2004 00:16, Tom Lane wrote:
> > Call me crazy, but maybe we have to throw a message for primary
> > key lookups on foreign key tables without indexes. I hate to throw a
> > message on update/delete rather than create table, but I don't see
> > another way.
>
> I don't think tha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Looking at what we have, we know every table will get some inserts, and
> we know every insert will have to check the primary key. What we don't
> know is if there will be any modifications or deletes to the primary
> key.
Yeah. It's possible that the
Tom Lane wrote:
> While reviewing Fabien Coelho's patch for emitting warnings for slow
> foreign-key checks, it occurred to me that we aren't covering all bases.
> The patch as committed makes sure that there is a usable index on the
> referenced table, but it does not look for one on the referenci
While reviewing Fabien Coelho's patch for emitting warnings for slow
foreign-key checks, it occurred to me that we aren't covering all bases.
The patch as committed makes sure that there is a usable index on the
referenced table, but it does not look for one on the referencing table.
Failure to pro
22 matches
Mail list logo
