On Wed, Aug 27, 2014 at 1:02 AM, Alex Goncharov <
alex.goncharov@gmail.com> wrote:
> > Thank you, Kevin -- this is helpful.
>
> Thank you David, too.
>
>
> > But it still leaves questions for me.
>
> Still...
>
>
> Alex Goncharov wrote:
>
> >>> How do I decide, before starting a COPY data loa
On Mon, Aug 25, 2014 at 9:40 AM, Emi Lu wrote:
>
> By the way, could someone let me know why set autocommit(false) is for
> sure faster than true please? Or, some online docs talk about this.
>
>
Not sure about the docs specifically but:
Commit is expensive because as soon as it is issued all o
Please do not top-posts on these lists.
On Wednesday, June 4, 2014, Huang, Suya wrote:
> Thank you David, I copied the detailed activity from the report as below.
> As it shows, it has prepare and bind queries. One of the item has
> Bind/Prepare pretty high as 439.50. so that looks like a good
gianfranco caca wrote
> Hai,
>
> Can anyone tell me the difference and performance between pgdump and
> pg_basebackup if I want to backup a large database.
>
> Thanks
Yes. And many of their words have been written down in the documentation in
a chapter named "Backup and Restore". Do you have a
Sethu Prasad wrote
> Reaching the maxPoolSize from the minPoolSize means creating the
> connections at the crucial moment where the client application is in the
> desperate need of completing an important query/transaction which the
> primary responsibility since it cannot hold the data collected.
Guillaume Smet wrote
> Brett Wooldridge, the creator of HikariCP [1] - a high performance
> Java connection pool - is contemplating the idea to change the way
> pooling is done in HikariCP and have a fixed-size pool of connections
> always open.
>
> No maxPoolSize, no minIdle, no minPoolSize, just
r@
> [mailto:
> pgsql-performance-owner@
> ] On Behalf Of David Johnston
> Sent: Friday, March 07, 2014 11:53 AM
> To:
> pgsql-performance@
> Subject: Re: [PERFORM] Slow query
>
> Bikram Kesari Naik wrote
>> Hi,
>>
>> I have a view which joins mu
Bikram Kesari Naik wrote
> Hi,
>
> I have a view which joins multiple tables to give me a result. It takes
> more than a minute to give me the result on psql prompt when I select all
> the data from that view.
> The single CPU which is used to run this query is utilized 100%.Even if I
> fire a c
kolsze...@gmail.com wrote
> Thanx for your answer
>
> My example is trivial because i want to show strange (for me) postgres
> behavior with dealing with primary keys (extreme example), in real
> situation user put search condition e.g. "Panas" and this generates query
> ...
> where gd.other_code
Krzysztof Olszewski wrote
> Hi,
>
> my sql is very simple,
> returns one row,
> where conditions are assigned to primary keys
>
>
> */select g.gd_index, gd.full_name/**/
> /**/from gd g join gd_data gd on (g.id_gd = gd.id_gd)/**/
> /**/where gd.id_gd_data = OR g.id_gd = ;/*
>
>
> but
maxabbr wrote
> Hello,
>
> We are starting a new project to deploy a solution in cloud with the
> possibility to be used for 2.000+ clients. Each of this clients will use
> several tables to store their information (our model has about 500+ tables
> but there's less than 100 core table with heavy
Ben Hoyt wrote
> * http://www.postgresql.org/message-id/
> 51A11C97.90209@
> --
> indicates that the db ignores the index when add constraints
As noted in the referenced thread (and never contradicted) the current
algorithm is "for each record does the value in the FK column exist in the
PK tab
Samuel Stearns-2 wrote
> EXPLAIN:
>
> QUERY PLAN
>
> ---
Samuel Stearns-2 wrote
> Total RAM - 1G
>
>
> 1. Explain on SELECT.
So either this is a typo (1 GB of RAM) or your query is likely ending up I/O
bound.
You should probably provide EXPLAIN and EXPLAIN (ANALYZE) output since even
with the schema it is impossible for someone to see what the
Sergey Konoplev-2 wrote
> As an alternative solution for pagination (OFFSET) problem you might
> also use the "prev/next" technique, like
>
> SELECT * FROM table
> WHERE id > :current_last_id
> ORDER BY id LIMIT 10
>
> for "next", and
>
> SELECT * FROM (
> SELECT * FROM table
> WHERE id
Ellen Rothman wrote
> I have the same table definition in two different databases on the same
> computer.
You really should prove this to us by running schema commands on the table
and providing results.
Also, version information has not been provided and you do not state whether
the databases a
David Carpio wrote
> I have made some changes in my postgresql.conf, well, I made two changes
> in this file. the first time, my queries had improved on their execution
> time considerably but in the second change, I seem my queries have not
> improved on the contrary they have come back to be s
Yuri Levinsky wrote
>> We have two equals queries where the sole difference is in the limit.
>> - The first is hard coded with limit 500.
>> - The second is prepared with limit $1 ($1 is bound to 500).
>
>
>> PostgreSQL give us two different plans with a huge execution time for
>> the
> prepared
18 matches
Mail list logo
