Понеділок, 9 липня 2012 р. користувач Misa Simic
написав:
>
>
> 2012/7/9 Gregg Jaskiewicz
>>
>> Use cursors.
>> By far the most flexible. offset/limit have their down sides.
>
>
> Well, I am not aware what down sides there are in LIMIT OFFSET what does
not exist in any other solutions for paged q
Понеділок, 9 липня 2012 р. користувач Misa Simic
написав:
>
>
> 2012/7/9 Gregg Jaskiewicz
>>
>> Use cursors.
>> By far the most flexible. offset/limit have their down sides.
>
>
> Well, I am not aware what down sides there are in LIMIT OFFSET what does
not exist in any other solutions for paged q
On Mon, Jul 9, 2012 at 4:50 PM, Craig Ringer wrote:
>
>
> When/if you do need a count of a single table without any filters, a common
> trick is to use table statistics to return an approximation. If your
> autovaccum is running regularly it's usually a very good approximation, too.
>
> Sounds lik
On 07/10/2012 06:24 AM, Misa Simic wrote:
Hi Andrew,
Sure... We are sending data in Json to clients
{
total:6784,
data:[50 rows for desired page]
}
SELECT count(*) FROM table - without where, without joins used to have
bad performance... However, in real scenario we have never had the case
wit
On 07/09/2012 09:22 PM, Shaun Thomas wrote:
On 07/09/2012 07:02 AM, Craig Ringer wrote:
Do do cursors.
Did you mean "Do not use cursors" here?
Oops. "So do cursors".
Then the user goes away on a week's holiday and leaves their PC at
your "next" button.
This exactly. Cursors have limited
her page) if calculation is
done, return results from cache (with real total number)... But it is
really on very exceptional basis then on regular...
Cheers
Misa
Sent from my Windows Phone
From: Andrew Dunstan
Sent: 09/07/2012 19:47
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] P
On Mon, Jul 9, 2012 at 1:46 PM, Andrew Dunstan wrote:
>
> On 07/09/2012 01:41 PM, Misa Simic wrote:
>
>>
>>
>> From my experience users even very rare go to ending pages... easier to
>> them would be to sort data by field to get those rows in very first pages...
>>
>>
>>
>
> Yeah, the problem rea
On 07/09/2012 01:41 PM, Misa Simic wrote:
From my experience users even very rare go to ending pages... easier
to them would be to sort data by field to get those rows in very first
pages...
Yeah, the problem really is that most client code wants to know how many
pages there are, even
2012/7/9 Gregg Jaskiewicz
> Use cursors.
> By far the most flexible. offset/limit have their down sides.
>
Well, I am not aware what down sides there are in LIMIT OFFSET what does
not exist in any other solutions for paged queries... But agree there
always must be some compromise between flexib
On Mon, Jul 9, 2012 at 8:16 AM, Craig James wrote:
>
> A good solution to this general problem is "hitlists." I wrote about this
> concept before:
>
> http://archives.postgresql.org/pgsql-performance/2010-05/msg00058.php
>
>
I implemented this exact strategy in our product years ago. Our queri
On Mon, Jul 9, 2012 at 6:22 AM, Shaun Thomas wrote:
> On 07/09/2012 07:02 AM, Craig Ringer wrote:
>
> Do do cursors.
>>
>
> Did you mean "Do not use cursors" here?
>
> Then the user goes away on a week's holiday and leaves their PC at
>> your "next" button.
>>
>
> This exactly. Cursors have limi
On 07/09/2012 07:02 AM, Craig Ringer wrote:
Do do cursors.
Did you mean "Do not use cursors" here?
Then the user goes away on a week's holiday and leaves their PC at
your "next" button.
This exactly. Cursors have limited functionality that isn't directly
disruptive to the database in gene
On 07/09/2012 07:55 PM, Gregg Jaskiewicz wrote:
Use cursors.
By far the most flexible. offset/limit have their down sides.
Do do cursors.
Keeping a cursor open across user think time has resource costs on the
database. It doesn't necessarily require keeping the transaction open
(with hold cur
Use cursors.
By far the most flexible. offset/limit have their down sides.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Hi Hermann,
Well,
Not clear how you get rows for user without paging?
If it is some query:
SELECT columns FROM table WHERE UserHasPerimision(rowPK, userid)
Paging would be:
SELECT columns FROM table WHERE UserHasPerimision(rowPK, userid) LIMIT
NoOfRecords OFFSET page*NoOfRecords
Kind Regards
On Wed, Jul 4, 2012 at 6:25 AM, Hermann Matthes wrote:
> I want to implement a "paged Query" feature, where the user can enter in a
> dialog, how much rows he want to see. After displaying the first page of
> rows, he can can push a button to display the next/previous page.
> On database level I c
Hermann Matthes wrote:
> I want to implement a "paged Query" feature, where the user can enter
in
> a dialog, how much rows he want to see. After displaying the first
page
> of rows, he can can push a button to display the next/previous page.
> On database level I could user "limit" to implement th
What language are you using? Usually there is iterator with chunked fetch
option (like setFetchSize in java jdbc). So you are passing query without
limit and then read as many results as you need. Note that query plan in
this case won't be optimized for your limit and I don't remember if
postgres h
I want to implement a "paged Query" feature, where the user can enter in
a dialog, how much rows he want to see. After displaying the first page
of rows, he can can push a button to display the next/previous page.
On database level I could user "limit" to implement this feature. My
problem now i
19 matches
Mail list logo
