Re: [pgAdmin4][Patch]: To handle long numbers for Rows (estimated) field in Table's properties

Oops..that was due to float4->text (rel.reltuples::text) datatype casting
in postgres.

Please find updated patch.

On Thu, Nov 2, 2017 at 2:31 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> Hi
>
> I created a table with:
>
> create table bigun as select * from generate_series(0, 1000000)
>
> I then selected it in the treeview, and it showed 0 for estimated rows,
> and nothing at all for counted rows. I ran a vacuum full on the new table,
> and now it fails to display the properties. On the console I see:
>
> Exception in thread Thread-1618:
> Traceback (most recent call last):
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py",
> line 810, in __bootstrap_inner
> self.run()
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py",
> line 763, in run
> self.__target(*self.__args, **self.__kwargs)
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> lib/python2.7/SocketServer.py", line 602, in process_request_thread
> self.handle_error(request, client_address)
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> lib/python2.7/SocketServer.py", line 599, in process_request_thread
> self.finish_request(request, client_address)
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> lib/python2.7/SocketServer.py", line 334, in finish_request
> self.RequestHandlerClass(request, client_address, self)
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> lib/python2.7/SocketServer.py", line 655, in __init__
> self.handle()
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py",
> line 200, in handle
> rv = BaseHTTPRequestHandler.handle(self)
> File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> lib/python2.7/BaseHTTPServer.py", line 340, in handle
> self.handle_one_request()
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py",
> line 235, in handle_one_request
> return self.run_wsgi()
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py",
> line 177, in run_wsgi
> execute(self.server.app)
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/werkzeug/serving.py",
> line 165, in execute
> application_iter = app(environ, start_response)
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
> line 2000, in __call__
> return self.wsgi_app(environ, start_response)
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
> line 1991, in wsgi_app
> response = self.make_response(self.handle_exception(e))
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
> line 1567, in handle_exception
> reraise(exc_type, exc_value, tb)
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
> line 1988, in wsgi_app
> response = self.full_dispatch_request()
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
> line 1641, in full_dispatch_request
> rv = self.handle_user_exception(e)
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
> line 1544, in handle_user_exception
> reraise(exc_type, exc_value, tb)
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
> line 1639, in full_dispatch_request
> rv = self.dispatch_request()
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py",
> line 1625, in dispatch_request
> return self.view_functions[rule.endpoint](**req.view_args)
> File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/views.py",
> line 84, in view
> return self.dispatch_request(*args, **kwargs)
> File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/utils.py", line
> 242, in dispatch_request
> return method(*args, **kwargs)
> File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_
> groups/servers/databases/schemas/tables/utils.py", line 150, in wrap
> return f(*args, **kwargs)
> File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_
> groups/servers/databases/schemas/tables/__init__.py", line 574, in
> properties
> estimated_row_count = int(res['rows'][0].get('reltuples', 0))
> ValueError: invalid literal for int() with base 10: '1e+06'
>
>
> On Wed, Nov 1, 2017 at 4:28 PM, Murtuza Zabuawala <murtuza.zabuawala@
> enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> Please find updated patch with suggested changes.
>>
>>
>> On Wed, Nov 1, 2017 at 8:42 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>>
>>>
>>> On Wed, Nov 1, 2017 at 2:40 PM, Murtuza Zabuawala <
>>> murtuza(dot)zabuawala(at)enterprisedb(dot)com> wrote:
>>>
>>>> In my opinion, displaying 2000+ instead of actual value doesn't looks
>>>> good.
>>>>
>>>> Let say my threshold is set to 5000 and I have 1million rows,
>>>> displaying 5000+ instead of actual value doesn't looks good.
>>>> OR
>>>> What we can do is, we can hide the field if it is empty/or less than
>>>> threshold.
>>>>
>>>
>>> I don't think it would necessarily look bad - after all, the estimated
>>> row count will be displayed right above it.
>>>
>>>
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> On Wed, Nov 1, 2017 at 7:55 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 1, 2017 at 2:25 PM, Harshal Dhumal <
>>>>> harshal(dot)dhumal(at)enterprisedb(dot)com> wrote:
>>>>>
>>>>>> Hi Murtuza,
>>>>>>
>>>>>> I think for tables having row count more than preference count it
>>>>>> should show preference count with plus '+' sign instead empty.
>>>>>> eg. 2000+ (for table with rows more than 2000 and for preference
>>>>>> count of 2000.)
>>>>>>
>>>>>
>>>>> That's a nice idea.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> [image: Inline image 1]
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Harshal Dhumal*
>>>>>> *Sr. Software Engineer*
>>>>>>
>>>>>> EnterpriseDB India: http://www.enterprisedb.com
>>>>>> The Enterprise PostgreSQL Company
>>>>>>
>>>>>> On Wed, Nov 1, 2017 at 7:38 PM, Murtuza Zabuawala <
>>>>>> murtuza(dot)zabuawala(at)enterprisedb(dot)com> wrote:
>>>>>>
>>>>>>> Hi Dave,
>>>>>>>
>>>>>>> Please find updated patch.
>>>>>>>
>>>>>>> ​-- Murtuza​
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Nov 1, 2017 at 6:50 PM, Murtuza Zabuawala <
>>>>>>> murtuza(dot)zabuawala(at)enterprisedb(dot)com> wrote:
>>>>>>>
>>>>>>>> Thanks Dave, I'll check the implementation in pgAdmin3 & send new
>>>>>>>> patch with suggested changes.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Nov 1, 2017 at 6:41 PM, Dave Page <dpage(at)pgadmin(dot)org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> On Wed, Nov 1, 2017 at 11:58 AM, Murtuza Zabuawala <
>>>>>>>>> murtuza(dot)zabuawala(at)enterprisedb(dot)com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> PFA patch to fix the issue where "Rows (estimated)" field was not
>>>>>>>>>> displaying long number properly.
>>>>>>>>>> RM#2386
>>>>>>>>>>
>>>>>>>>>> I have also added the code to count actual rows in a table [
>>>>>>>>>> "Rows (counted)" filed ] which was missing.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Oops. Well the idea is good, but unfortunately we want to be
>>>>>>>>> careful about when we count the rows, as we could have just clicked on a
>>>>>>>>> 10B row table which would take a while. To avoid that, pgAdmin III would
>>>>>>>>> only count the rows in the table if the estimated number of rows was below
>>>>>>>>> a specific value (see File -> Preferences -> Browser -> Properties ->
>>>>>>>>> "Count rows if estimated less than").
>>>>>>>>>
>>>>>>>>> I think we need to do the same here - add a preferences option,
>>>>>>>>> and only count if estimated is greater than the specified value (the
>>>>>>>>> default for which was 2000 in pgAdmin III I believe).
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Dave Page
>>>>>>>>> Blog: http://pgsnake.blogspot.com
>>>>>>>>> Twitter: @pgsnake
>>>>>>>>>
>>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>>>>>> The Enterprise PostgreSQL Company
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dave Page
>>>>> Blog: http://pgsnake.blogspot.com
>>>>> Twitter: @pgsnake
>>>>>
>>>>> EnterpriseDB UK: http://www.enterprisedb.com
>>>>> The Enterprise PostgreSQL Company
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>>
>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>