On 19 September 2014 13:51, Björn Wittich wrote:
> Hi mailing list,
>
> I am relatively new to postgres. I have a table with 500 coulmns and about
> 40 mio rows. I call this cache table where one column is a unique key
> (indexed) and the 499 columns (type integer) are some values belonging to
>
On 18 March 2014 22:26, Yu Zhao wrote:
> In PostgreSQL 9.3.3 Documentation 11.8. Partial Indexes Example 11-2
> (http://www.postgresql.org/docs/9.3/interactive/indexes-partial.html),
> the partial index is created
>
> CREATE INDEX orders_unbilled_index ON orders (order_nr) WHERE billed
> is not t
On 2 June 2013 21:39, Robert DiFalco wrote:
> I have a table called contacts. It has a BIGINT owner_id which references
> a record in the user table. It also has a BIGINT user_id which may be null.
> Additionally it has a BOOLEAN blocked column to indicate if a contact is
> blocked. The final det
On 1 March 2012 13:02, Marcin Mirosław wrote:
> W dniu 01.03.2012 12:50, Szymon Guz pisze:
> Hi Szymon,
> > If you have only 2 rows in the table, then the plan really doesn't
> > matter too much. Sorting two rows would be really fast :)
> >
> > Try to che
On 1 March 2012 12:45, Marcin Mirosław wrote:
> Hello,
> my example query (and explain) is:
> $ explain SELECT count(*) from (select * from users_profile order by id)
> u_p;
>QUERY PLAN
> ---
>
On 11 October 2011 21:13, Szymon Guz wrote:
>
>
> On 11 October 2011 21:08, Radhya sahal wrote:
>
>> Hi
>> I want to know how can i measure runtime query in postgresql if i use
>> command line psql?
>> not explain rutime for the query such as the runtime whi
On 11 October 2011 21:08, Radhya sahal wrote:
> Hi
> I want to know how can i measure runtime query in postgresql if i use
> command line psql?
> not explain rutime for the query such as the runtime which appear in
> pgadmin ?
> such as Total query runtime: 203 ms.
>
run this in psql:
\t
rega
On 11 October 2011 19:52, CS DBA wrote:
> Hi all ;
>
> I'm trying to tune a difficult query.
>
> I have 2 tables:
> cust_acct (9million rows)
> cust_orders (200,000 rows)
>
> Here's the query:
>
> SELECT
> a.account_id, a.customer_id, a.order_id, a.primary_contact_id,
> a.status, a.cust
On 2 August 2011 08:42, Adarsh Sharma wrote:
> Dear all,
>
> Just want to know which join is better for querying data faster.
>
> I have 2 tables A ( 70 GB ) & B ( 7 MB )
>
> A has 10 columns & B has 3 columns.Indexes exist on both tables's ids.
>
> select p.* from table A p, B q where p.id=q.id
On 5 April 2011 21:25, Maria L. Wilson wrote:
> Would really appreciate someone taking a look at the query below
> Thanks in advance!
>
>
> this is on a linux box...
> Linux dsrvr201.larc.nasa.gov 2.6.18-164.9.1.el5 #1 SMP Wed Dec 9 03:27:37
> EST 2009 x86_64 x86_64 x86_64 GNU/Linux
>
> expl
On 5 November 2010 11:59, A B wrote:
> Hi there.
>
> If you just wanted PostgreSQL to go as fast as possible WITHOUT any
> care for your data (you accept 100% dataloss and datacorruption if any
> error should occur), what settings should you use then?
>
>
I'm just curious, what do you need that
2010/10/26 Grzegorz Jaśkiewicz
> 2010/10/26 Szymon Guz :
> >
> > Well, strange. Why is that slower?
>
> To answer that fully, you would need to see the implementation.
> suffice to say,
>
> count(a) does:
>
> if (a <> NULL)
> {
> count++;
>
2010/10/26 Grzegorz Jaśkiewicz
> implementation wise, count(*) is faster. Very easy to test:
>
> SELECT COUNT(*) FROM generate_series(1,100) a, generate_series(1,1000) b;
>
> SELECT COUNT(a) FROM generate_series(1,100) a, generate_series(1,1000) b;
>
>
> ;]
>
Well, strange. Why is that slower?
2010/10/26 Marcin Mirosław
> W dniu 26.10.2010 12:59, Szymon Guz pisze:
> > both queries are the same.
>
> IMHO they aren't the same, but they returns the same value in this case.
> I mean count(field) doesn't count NULL values, count(*) does it.
> I'm wr
On 26 October 2010 12:56, AI Rumman wrote:
> Which one is faster?
> select count(*) from talble
> or
> select count(id) from table
> where id is the primary key.
>
Check the query plan, both queries are the same.
regards
Szymon
lease.
>
Database knows, due to table statistics, that the query ">10" would return
small (1941) number of rows, while query "<1" would return big
(88851) number of rows. The "small" and "big" is quite relative, but the
result is that the database knows, that it would be faster not to use index,
if the number of returning rows is big.
regards
Szymon Guz
Regards,
> Davor
>
>
>
>
Hi,
show us the code of those two functions and explain analyze of those
queries.
regards
Szymon Guz
2010/6/10 AI Rumman
> I found only AccessShareLock in pg_locks during the query.
> And the query does not return data though I have been waiting for 10 mins.
>
> Do you have any idea ?
>
>
> On Thu, Jun 10, 2010 at 5:26 PM, Szymon Guz wrote:
>
>>
>>
>
ails| 44595 | 1360
> vtiger_seactivityrel | 1.31978e+06 | 6470
> vtiger_vantage_email_track | 88852 | 481
> (3 rows)
>
>
>
>
Could you define what you mean by 'hangs'? Does it work or not?
Check table pg_locks for locking issues, maybe the query is just slow but
not hangs.
Notice that the query just returns 2M rows, that can be quite huge number
due to your database structure, data amount and current server
configuration.
regards
Szymon Guz
ly recent data. I have an index on the row creation
> date and I would like almost all of my queries to have a query plan looking
> something like:
>
>
>
[CUT]
Do you have autovacuum running? Have you tried updating statistics?
regards
Szymon Guz
ing here as rows(2400). Could you explain this.
>
>
>
It is assuming that there are 2400 rows in this table. Probably you've
deleted some rows from the table leaving just one.
regards
Szymon Guz
y (the autovacuum work characteristic depends on
the settings for the database).
> Q2. Does explain , will update the catalogs automatically.
>
>
No, explain doesn't update table's statistics.
regards
Szymon Guz
22 matches
Mail list logo
