On Wed, Nov 06, 2019 at 03:15:53PM -0800, Andres Freund wrote:
Hi,
On 2019-11-06 22:54:48 +0100, Tomas Vondra wrote:
If we're only talking about FPGA I/O acceleration, essentially FPGA
between the database and storage, it's likely possible to get that
working without any extensive executor chan
On Thu, Nov 07, 2019 at 01:15:30PM +1300, David Rowley wrote:
> On Thu, 7 Nov 2019 at 11:59, Justin Pryzby wrote:
> >
> > On Mon, Nov 04, 2019 at 03:04:45AM +, David Wheeler wrote:
> > > Postgres version 9.5.19
> > > Each of the tables has between 3-4 indexes, and all the indexes include
> >
On Thu, 7 Nov 2019 at 11:59, Justin Pryzby wrote:
>
> On Mon, Nov 04, 2019 at 03:04:45AM +, David Wheeler wrote:
> > Postgres version 9.5.19
> > Each of the tables has between 3-4 indexes, and all the indexes include tid
> > as first parameter.
> But note that index definition will be prohi
Is default_statistics_target set above default 100? I would assume that would
reflect in the size of pg_statistic, but wanted to ask since increasing that
from 100 to 1000 was the only time I have seen planning time explode. Are other
queries slow to plan?
Looks like you’ve found it! Someone ha
Hi,
On 2019-11-06 22:54:48 +0100, Tomas Vondra wrote:
> If we're only talking about FPGA I/O acceleration, essentially FPGA
> between the database and storage, it's likely possible to get that
> working without any extensive executor changes. Essentially create an
> FPGA-aware variant of SeqScan a
On Mon, Nov 04, 2019 at 03:04:45AM +, David Wheeler wrote:
> Postgres version 9.5.19
> Each of the tables has between 3-4 indexes, and all the indexes include tid
> as first parameter.
On Mon, Nov 04, 2019 at 12:00:59AM -0500, Tom Lane wrote:
> If this *is* the cause, v11 and up have a perfor
Is default_statistics_target set above default 100? I would assume that
would reflect in the size of pg_statistic, but wanted to ask since
increasing that from 100 to 1000 was the only time I have seen planning
time explode. Are other queries slow to plan?
>> I'll try reindexing each of the tables just to make sure it's not strange
>> index imbalance or something causing the issue.
> I seen this issue few time - and reindex helps.
Alas our reindex doesn’t seem to have helped. I’m going to see if we can
reproduce this on a non-prod environment so w
On Wed, Nov 06, 2019 at 11:01:37AM -0700, AJG wrote:
From what I have read and benchmarks seen..
FPGA shines for writes (and up to 3x (as opposed to 10x claim) real world
for queries from memory)
GPU shines/outperforms FPGA for reads. There is a very recent and
interesting academic paper[1] on
>From what I have read and benchmarks seen..
FPGA shines for writes (and up to 3x (as opposed to 10x claim) real world
for queries from memory)
GPU shines/outperforms FPGA for reads. There is a very recent and
interesting academic paper[1] on High Performance GPU B-Tree (vs lsm) and
the incredibl
10 matches
Mail list logo
