I had a small play with this. Pretty cool to be able to track progress
for COPY and VACUUM jobs. For some reason I could never elicit any
numbers (other than the default Nan) for a query (tried 'SELECT count(*)
FROM pgbench_accounts' but figured aggregates probably don't qualify as
simple, and
Dimitri Fontaine writes:
> Robert Haas writes:
>> What you just said is about what I had in mind. I admit I can't
>> articulate a more detailed design right off the top of my head, but
>> the architecture you're proposing seems dead certain to never cover
>> more than 0.1% of what people actuall
Robert Haas writes:
> What you just said is about what I had in mind. I admit I can't
> articulate a more detailed design right off the top of my head, but
> the architecture you're proposing seems dead certain to never cover
> more than 0.1% of what people actually do.
Well, considering what we
On Fri, Sep 17, 2010 at 4:50 PM, Peter Eisentraut wrote:
> On tor, 2010-09-16 at 19:14 -0400, Robert Haas wrote:
>> I think that there should be a function which returns just this one
>> piece of data and is not automatically called as part of select * from
>> pg_stat_activity. Then we could even
On tor, 2010-09-16 at 19:14 -0400, Robert Haas wrote:
> I think that there should be a function which returns just this one
> piece of data and is not automatically called as part of select * from
> pg_stat_activity. Then we could eventually decide to give backends a
> way to know if that function
On Thu, Sep 16, 2010 at 4:57 PM, Peter Eisentraut wrote:
> On tor, 2010-09-16 at 15:56 -0400, Robert Haas wrote:
>> I reiterate my earlier criticism of this whole approach: it seems to
>> assume that computing query progress is something inexpensive enough
>> that we can afford to do it regardless
On tor, 2010-09-16 at 15:56 -0400, Robert Haas wrote:
> I reiterate my earlier criticism of this whole approach: it seems to
> assume that computing query progress is something inexpensive enough
> that we can afford to do it regardless of whether anyone is looking.
That assumption appears to hold
On Thu, Sep 16, 2010 at 2:52 PM, Peter Eisentraut wrote:
>> > a very simple query.
>> SELECT * FROM tbl;
>> can report reasonable progress, but
>> SELECT count(*) FROM tbl;
>> cannot, because planned_tuple_count of the aggregation is 1.
>> I hope better solutions for the grouping case because
On tor, 2010-09-16 at 15:47 +0900, Itagaki Takahiro wrote:
> On Tue, Aug 17, 2010 at 2:19 PM, Peter Eisentraut wrote:
> > VACUUM (lazy) (also autovacuum), table-rewriting ALTER TABLE
> We could also support VACUUM FULL, CLUSTER, CREATE INDEX and REINDEX.
Well, yeah, but those are a lot harder to
On Tue, Aug 17, 2010 at 2:19 PM, Peter Eisentraut wrote:
> Here is a small prototype for a query progress indicator.
I read and tested the patch. Here are comments to the code itself.
- Oid of pg_stat_get_backend_progress() must be changed because we are using
the id for another function.
- On
On Aug 18, 2010, at 9:02 AM, Robert Haas wrote:
> On Wed, Aug 18, 2010 at 8:45 AM, Greg Stark wrote:
>> On Tue, Aug 17, 2010 at 11:29 PM, Dave Page wrote:
>>> Which is ideal for monitoring your own connection - having the info in
>>> the pg_stat_activity is also valuable for monitoring and syst
On ons, 2010-08-18 at 13:45 +0100, Greg Stark wrote:
> But progress bars alone aren't really the big prize. I would really
> love to see the explain plans for running queries.
The auto_explain module does that already.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On tis, 2010-08-17 at 13:52 -0400, Stephen Frost wrote:
> I don't like how the backend would have to send something NOTICE-like,
> I had originally been thinking "gee, it'd be nice if psql could query
> pg_stat while doing something else", but that's not really possible...
> So, I guess NOTICE-like
On Wed, Aug 18, 2010 at 8:45 AM, Greg Stark wrote:
> On Tue, Aug 17, 2010 at 11:29 PM, Dave Page wrote:
>> Which is ideal for monitoring your own connection - having the info in
>> the pg_stat_activity is also valuable for monitoring and system
>> administration. Both would be ideal :-)
>
> Hm, I
On 18 August 2010 13:45, Greg Stark wrote:
> On Tue, Aug 17, 2010 at 11:29 PM, Dave Page wrote:
>> Which is ideal for monitoring your own connection - having the info in
>> the pg_stat_activity is also valuable for monitoring and system
>> administration. Both would be ideal :-)
>
> Hm, I think I
On Tue, Aug 17, 2010 at 11:29 PM, Dave Page wrote:
> Which is ideal for monitoring your own connection - having the info in
> the pg_stat_activity is also valuable for monitoring and system
> administration. Both would be ideal :-)
Hm, I think I've come around to the idea that having the info in
On Tue, Aug 17, 2010 at 10:53 PM, Greg Stark wrote:
> (Sorry for top posting and for any typos -- typing on my phone)
>
> In my earlier patch to do progress indicators for arbitrary SQL queries I
> had envisioned a setup similar to how we handle query cancellation. Psql
> could support a key like
(Sorry for top posting and for any typos -- typing on my phone)
In my earlier patch to do progress indicators for arbitrary SQL queries I
had envisioned a setup similar to how we handle query cancellation. Psql
could support a key like SIGINFO which would make it request an update.
Clients like pg
--On 17. August 2010 20:08:51 +0200 Erik Rijkers wrote:
How can I 'change OID'? This error comes out of an initial initdb run.
(There are several other test-instances on this machine (several
running), but with their own $PGDATA, $PGPORT. - they can't interfere
with each other, can they?)
On Tue, August 17, 2010 19:13, Peter Eisentraut wrote:
> On tis, 2010-08-17 at 15:59 +0200, Erik Rijkers wrote:
>> creating template1 database in
>> /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data/base/1
>> ... FATAL: could not
>> create unique index "pg_proc_oid_index"
>> DETA
* Alex Hunsaker (bada...@gmail.com) wrote:
> On Tue, Aug 17, 2010 at 06:31, Stephen Frost wrote:
> > * Peter Eisentraut (pete...@gmx.net) wrote:
> >> Other comments?
> >
> > Will we be able to use it for psql while keeping just one database
> > connection? I assume the answer is 'no', but it sure
On Tue, Aug 17, 2010 at 06:31, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> Other comments?
>
> Will we be able to use it for psql while keeping just one database
> connection? I assume the answer is 'no', but it sure would be nice..
I think thats something that could be
On tis, 2010-08-17 at 15:59 +0200, Erik Rijkers wrote:
> creating template1 database in
> /var/data1/pg_stuff/pg_installations/pgsql.progress_indicator/data/base/1 ...
> FATAL: could not
> create unique index "pg_proc_oid_index"
> DETAIL: Key (oid)=(2614) is duplicated.
Probably merge conflict
On tis, 2010-08-17 at 08:31 -0400, Stephen Frost wrote:
> Will we be able to use it for psql while keeping just one database
> connection? I assume the answer is 'no', but it sure would be nice..
How do you expect that to behave? I suppose the backend could send
NOTICE-like messages every 1% or
On Tue, August 17, 2010 07:19, Peter Eisentraut wrote:
> Here is a small prototype for a query progress indicator.
>
The patch applies to cvs HEAD (9.1devel) and compiles OK, but make check fails.
./configure
--prefix=/var/data1/pg_stuff/pg_installations/pgsql.progress_indicator
--with-pgport=65
* Peter Eisentraut (pete...@gmx.net) wrote:
> Other comments?
Will we be able to use it for psql while keeping just one database
connection? I assume the answer is 'no', but it sure would be nice..
Perhaps psql could do something for \copy commands, anyway, but it'd be
independent.
Than
Here is a small prototype for a query progress indicator.
Past discussions seemed to indicate that the best place to report this
would be in pg_stat_activity. So that's what this does. You can try it
out with any of the following (on a sufficiently large table): VACUUM
(lazy) (also autovacuum),
27 matches
Mail list logo
