Re: How to read query plan - Mailing list pgsql-performance

From Miroslav Šulc
Subject Re: How to read query plan
Date
Msg-id 423499A9.5080504@startnet.cz
Whole thread Raw
In response to Re: How to read query plan  (John Arbash Meinel <john@arbash-meinel.com>)
List pgsql-performance
John Arbash Meinel wrote:

> Is there a reason to use varchar(1) instead of char(1). There probably
> is 0 performance difference, I'm just curious.

No, not at all. I'm just not used to char().

> Well, with cursors you can also do "FETCH ABSOLUTE 1 FROM
> <cursor_name>", which sets the cursor position, and then you can "FETCH
> FORWARD 30".
> I honestly don't know how the performance will be, but it is something
> that you could try.

This is science for me at this moment :-)

>> For display of single page consisting of 30 rows. The reason I query
>> all rows is that this is one of the filters users can use. User can
>> display just bigboards or billboards (or specify more advanced
>> filters) but he/she can also display AdDevices without any filter
>> (page by page). Before I select the 30 row, I need to order them by a
>> key and after that select the records, so this is also the reason why
>> to ask for all rows. The key for sorting might be different for each
>> run.
>>
> How are you caching the information in the background in order to
> support paging? Since you aren't using limit/offset, and you don't seem
> to be creating a temporary table, I assume you have a layer inbetween
> the web server and the database (or possibly inside the webserver) which
> keeps track of current session information. Is that true?

I just need three information:
1) used filter (stored in session, identified by filter index in query
string)
2) page length (static predefined)
3) what page to display (in query string)

>> In fact, on MySQL I didn't see any slow reactions so I didn't measure
>> and inspect it. But I can try it if I figure out how to copy the
>> database from PostgreSQL to MySQL.
>
>
> I figured you still had a copy of the MySQL around to compare to. You
> probably don't need to spend too much time on it yet.

It's not so simple because there are some differences between MySQL and
PostgreSQL in how they handle case sensitivity etc. The database table
structures are not the same too because of different data types support
and data values support.

>
> John
> =:->

Miroslav

Attachment

pgsql-performance by date:

Previous
From: Miroslav Šulc
Date:
Subject: Re: How to read query plan
Next
From: Tom Lane
Date:
Subject: Re: How to read query plan