On Fri, Mar 24, 2017 at 11:06 PM, Simon Riggs wrote:
> On 1 March 2017 at 01:36, Amit Langote wrote:
>
>> I don't know which way you're thinking of fixing this, but a planner patch
>> to implement faster partition-pruning will have taken care of this, I
>> think. As you may know, even declarativ
Hi Simon,
> > I don't know which way you're thinking of fixing this, but a planner patch
> > to implement faster partition-pruning will have taken care of this, I
> > think. As you may know, even declarative partitioned tables currently
> > depend on constraint exclusion for partition-pruning and
On 1 March 2017 at 01:36, Amit Langote wrote:
> I don't know which way you're thinking of fixing this, but a planner patch
> to implement faster partition-pruning will have taken care of this, I
> think. As you may know, even declarative partitioned tables currently
> depend on constraint exclus
Hi Tels,
Thanks a lot for the review!
> "corresponding"
Fixed.
> Also a question: Some one-line comments are
>
> /* Comment. */
>
> while others are
>
> /*
> * Comment.
> */
>
> Why the difference?
I'm trying to follow a code stile used in a code I'm modifying. In this
case I got an
Hi Aleksander,
noticed this in your patch:
> * Add a corespinding entry to pgStatTabHash.
"corresponding"
Also a question: Some one-line comments are
/* Comment. */
while others are
/*
* Comment.
*/
Why the difference?
Hope this helps,
Tels
PS: Sorry if this appears twice, I fumble
Hi Aleksander,
noticed this in your patch:
> * Add a corespinding entry to pgStatTabHash.
"corresponding"
Also a question: Some one-line comments are
/* Comment. */
while others are
/*
* Comment.
*/
Why the difference?
Hope this helps,
Tels
--
Sent via pgsql-hackers mailing list
Hi Amit,
> Sorry, I didn't mean to dissuade you from trying those
> micro-optimizations. If general inheritance cases can benefit from it
> (which, until we have a different method, will be used by partitioned
> tables as well), I think we should try it.
OK, I'll see what could be done here as w
Hi, Andres
Thanks a lot for the review!
> Why are we keeping that list / the "batch" allocation pattern? It
> doesn't actually seem useful to me after these changes. Given that we
> don't shrink hash-tables, we could just use the hash-table memory for
> this, no?
I don't think we can do that. A
Hi Aleksander,
On 2017/03/07 0:22, Aleksander Alekseev wrote:
> Hello.
>
> OK, here is a patch.
>
> Benchmark, before:
>
> ```
> number of transactions actually processed: 1823
> latency average = 1153.495 ms
> latency stddev = 154.366 ms
> tps = 6.061104 (including connections establishing)
>
Hi,
This issue has bothered me in non-partitioned use-cases recently, so
thanks for taking it up.
On 2017-03-06 18:22:17 +0300, Aleksander Alekseev wrote:
> diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
> index 2fb9a8bf58..fa906e7930 100644
> --- a/src/backend/po
Hello.
OK, here is a patch.
Benchmark, before:
```
number of transactions actually processed: 1823
latency average = 1153.495 ms
latency stddev = 154.366 ms
tps = 6.061104 (including connections establishing)
tps = 6.061211 (excluding connections establishing)
```
Benchmark, after:
```
number
Hi,
On 2017/02/28 23:25, Aleksander Alekseev wrote:
> Hello.
>
> I decided to figure out whether current implementation of declarative
> partitioning has any bottlenecks when there is a lot of partitions. Here
> is what I did [1].
Thanks for sharing.
> Then:
>
> ```
> # 2580 is some pk that ex
12 matches
Mail list logo