Hi,
On 30 August 2011 15:36, Szymon Kosok wrote:
> Hello,
>
> I asked that question on StackOverflow, but didn't get any valuable
> response, so I'll ask it here. :)
>
> I have such query:
Could you please re-post your explain using this web site:
http://explain.depesz.com/ and post links to Sta
Hi,
2011/8/30 Szymon Kosok :
> 2011/8/30 Ondrej Ivanič :
>> Could you please re-post your explain using this web site:
>> http://explain.depesz.com/ and post links to Stackoverflow question?
>
> Here it is: http://explain.depesz.com/s/Iaa
>
>> - try to
Hi,
On 12 September 2011 12:28, Stephen Frost wrote:
> Once those are done, you can query against the 'parent' table with
> something like:
> select * from parent where date = '2010-01-01';
>
> And PG will realize it only has to look at table2 to get the results for
> that query. This means the
Hi,
On 19 September 2011 11:14, Craig James wrote:
> DBsig for a hash-collision chain is always the bitwise OR of every record in
> that hash-collision chain. When you add a record to the hash table, you do
> a bitwise OR of its signature into the existing DBsig. If you delete a
> record, you e
Hi,
On 30 September 2011 01:08, Kevin Grittner wrote:
>> Is there a suggested number of child tables for table
>> partitioning,
>
> Generally, don't go over about 100 partitions per table.
Having 365 partitions per table is fine...
--
Ondrej Ivanic
(ondrej.iva...@gmail.com)
--
Sent via pgsql
Hi,
On 4 October 2011 21:25, Venkat Balaji wrote:
> I got hold of two catalog tables "pg_stats" and "pg_class".
> Column "avg_width" and "distinct" in pg_stats gets me lot of sensible
> information regarding, column values and size of the column.
> Can someone help me know when the values in thes
Hi,
On 8 December 2011 02:15, Christiaan Willemsen wrote:
> Currently, we are running into serious performance problems with our
> paritioning setup, because index lookups are mostly done on allpartions, in
> stead of the one partition it should know that it can find the needed row.
Planner is n
Hi,
On 28 December 2011 05:12, Tom Lane wrote:
> Possibly raising the stats target on emsg_messages would help.
In the function std_typanalyze() is this comment:
/*
* The following choice of minrows is based on the paper
* "Random sampling for histog
Hi,
On 25 May 2012 14:54, Hugo wrote:
> Thanks for the replies. The number of relations in the database is really
> high (~500,000) and I don't think we can shrink that. The truth is that
> schemas bring a lot of advantages to our system and postgresql doesn't show
> signs of stress with them. S
Hi,
On 3 August 2012 19:14, wrote:
> I want to add to table "Item" a column "a_elements" (array type of big
> integers) Every record would have not more than 50-60 elements in this
> column.
> After that i would create index GIN on this column and typical select should
> look like this:
> select
Hi,
On 16 August 2012 15:40, J Ramesh Kumar wrote:
> As you said, MySQL with MyISAM is better choice for my app. Because I don't
> need transaction/backup. May be I'll try with InnoDB and find the disk
> write/space difference. Is there any similar methods available in postgresql
> like MyISAM en
Hi,
On 24 September 2012 20:33, Kiriakos Tsourapas wrote:
> The problem : Postgres is becoming slow, day after day, and only a full
> vacuum fixes the problem.
>
> Information you may need to evaluate :
>
> The problem lies on all tables and queries, as far as I can tell, but we can
> focus on a
Hi,
On 25 September 2012 21:10, Kiriakos Tsourapas wrote:
> Suggestion noted.
> Nevertheless, I cannot imagine what it would help. Actually, the cost_delay
> makes autovacuum freeze when it takes more time than expected, therefore,
> having it enabled should help the system.
Yes, and I think tha
Hi,
On 10 October 2012 19:11, Julien Cigar wrote:
>> shared_buffers = 10GB
>
>
> Generally going over 4GB for shared_buffers doesn't help.. some of the
> overhead of bgwriter and checkpoints is more or less linear in the size of
> shared_buffers ..
Nothing is black or white; It's all shades of G
Hi,
On 12 October 2012 15:14, Korisk wrote:
> Strange situation.
> After indexscan enabling the cost is seriously decreased.
You can not really disable any scan method. enable_xxx = off just sets
very high cost (=100) for that operation.
--
Ondrej Ivanic
(ondrej.iva...@gmail.com)
(http
Hi,
On 16 October 2012 07:59, houmanb wrote:
> Dear all,
> We have a DB containing transactional data.
> There are about *50* to *100 x 10^6* rows in one *huge* table.
> We are using postgres 9.1.6 on linux with a *SSD card on PCIex* providing us
> a constant seeking time.
How many columns? What
Hi,
On 21 December 2012 04:29, Charles Gomes wrote:
> When I target the MASTER table on all the inserts and let
> the trigger decide what partition to choose from it takes 4 hours.
>
> If I target the partitioned table directly during the
> insert I can get 4 times better performance. It takes 1
17 matches
Mail list logo
