On Thu, 2019-05-02 at 01:05 -0400, Tom Lane wrote:
> Sergey Koposov writes:
> >
> > On Thu, 2019-05-02 at 00:36 -0400, Tom Lane wrote:
> > >
> > > What sort of selectivity estimator have you got attached to that custom
> > > operator?
> >
> > This is the code, but basically it is just a
Sergey Koposov writes:
> On Thu, 2019-05-02 at 00:36 -0400, Tom Lane wrote:
>> What sort of selectivity estimator have you got attached to that custom
>> operator?
> This is the code, but basically it is just a constant based on the search
> radius (which is the leftmost float argument of the
On Thu, 2019-05-02 at 00:36 -0400, Tom Lane wrote:
> Sergey Koposov writes:
> >
> > I'm currently trying to understand the expected row counts for a query
> > involving a nested loop join and bitmap index scan
> > on the functional index and a custom operator. And the numbers that I see
> >
Sergey Koposov writes:
> I'm currently trying to understand the expected row counts for a query
> involving a nested loop join and bitmap index scan
> on the functional index and a custom operator. And the numbers that I see
> don't make sense to me currently.
What sort of selectivity
To get the cluster up and running, you only need to move a GB or two.
On 5/1/19 9:24 PM, Igal Sapir wrote:
Thank you both. The symlink sounds like a very good idea. My other disk
is 100GB and the database is already 130GB so moving the whole thing will
require provisioning that will take more
Thank you both. The symlink sounds like a very good idea. My other disk
is 100GB and the database is already 130GB so moving the whole thing will
require provisioning that will take more time. I will try the symlinks
first. Possibly moving some tables to a tablespace on the other partition
to
Best optionCopy/move the entire pgdata to a larger space. It may also
be enough to just move the WAL (leaving a symlink) freeing up the 623M but
I doubt it since VACUUM FULL occurs in the same table space and can need an
equal amount of space (130G) depending on how much it can actually free
On Thu, 2 May 2019 at 12:07, Igal Sapir wrote:
> I mounted an additional partition with 100GB, hoping to fix the bloat with a
> TABLESPACE in the new mount, but how can I do anything if Postgres will not
> start in the first place?
You could move the pg_wal directory over to the new partition
Hi,
I'm currently trying to understand the expected row counts for a query
involving a nested loop join and bitmap index scan
on the functional index and a custom operator. And the numbers that I see don't
make sense to me currently. Hopefully
somebody here can shed some light on it, or
I have Postgres running in a Docker container with PGDATA mounted from the
host. Postgres consume all of the disk space, 130GB [1], and can not be
started [2]. The database has a lot of bloat due to much many deletions.
The problem is that now I can not start Postgres at all.
I mounted an
On Thu, May 2, 2019 at 8:26 AM Peter Geoghegan wrote:
> On Mon, Apr 29, 2019 at 7:45 AM rihad wrote:
> > Hi. Today we run pg_ctl promote on a slave server (10.7) and started
> > using it as a master. The OS also got upgraded FreeBSD 10.4 -> FreeBSD
> > 11.2. And you guessed it, most varchar
On Mon, Apr 29, 2019 at 7:45 AM rihad wrote:
> Hi. Today we run pg_ctl promote on a slave server (10.7) and started
> using it as a master. The OS also got upgraded FreeBSD 10.4 -> FreeBSD
> 11.2. And you guessed it, most varchar indexes got corrupted because
> system local changed in subtle
On 5/1/19 11:04 AM, Francisco Olarte wrote:
Adrian:
On Wed, May 1, 2019 at 7:57 PM Adrian Klaver wrote:
You will have to explain further as I am not seeing it:
test_(postgres)# select '2019-05-01 9:52' <= '2019-05-01 24:00'::timestamp;
?column?
--
t
test_(postgres)# select
On Wed, May 1, 2019 at 8:04 PM Adrian Klaver wrote:
> You don't have to use the functions:
> test_(postgres)# select dt_fld from dt_test where dt_fld <@
> '[2019-02-01, 2019-03-01)'::daterange ;
I knew there have to be a cast syntax ( I should have said I try to
avoid casts as well ). I will
On 5/1/19 10:58 AM, Francisco Olarte wrote:
Adrian..
On Wed, May 1, 2019 at 7:50 PM Adrian Klaver wrote:
I should have made it clearer, my suggestion was mostly directed at
Franciso's example.
...
For this sort of thing, I have found range types to be a time and sanity
saver. Just throwing
Adrian:
On Wed, May 1, 2019 at 7:57 PM Adrian Klaver wrote:
> You will have to explain further as I am not seeing it:
> test_(postgres)# select '2019-05-01 9:52' <= '2019-05-01 24:00'::timestamp;
> ?column?
> --
> t
>
> test_(postgres)# select '2019-05-01 24:00' <= '2019-05-01
Adrian..
On Wed, May 1, 2019 at 7:50 PM Adrian Klaver wrote:
> I should have made it clearer, my suggestion was mostly directed at
> Franciso's example.
...
> For this sort of thing, I have found range types to be a time and sanity
> saver. Just throwing it out there.
I've had problems with the
Ok, I see that my assumptions were incorrect. In this instance, the use of
< date+1 will return what is expected, where my solution might not have.
For other circumstances, I want to explore tsrange.
And, no, I'm not in Avondale, CA, but Decatur, GA (a few miles from
Avondale Estates, where I
On 5/1/19 10:51 AM, Francisco Olarte wrote:
On Wed, May 1, 2019 at 7:37 PM Chuck Martin wrote:
Something like daterange would be a solution in some circumstances, but this
query is a user-generated one, and they don't have that much control over the
query. It has to be modified as needed
On Wed, May 1, 2019 at 7:37 PM Chuck Martin wrote:
>
> Something like daterange would be a solution in some circumstances, but this
> query is a user-generated one, and they don't have that much control over the
> query. It has to be modified as needed behind the scenes so that it produces
>
On 5/1/19 10:37 AM, Chuck Martin wrote:
Something like daterange would be a solution in some circumstances, but
this query is a user-generated one, and they don't have that much
control over the query. It has to be modified as needed behind the
scenes so that it produces the results they
Chuck:
On Wed, May 1, 2019 at 7:23 PM Chuck Martin wrote:
>
> Thanks for the extra information. It is indeed an indexed column. I'll have
> to think some more about how to address this in a general way, as this issue
> can come up all over. I suppose using
>
> AND datetime <= 'May 1, 2019
Something like daterange would be a solution in some circumstances, but
this query is a user-generated one, and they don't have that much control
over the query. It has to be modified as needed behind the scenes so that
it produces the results they expect. In this instance, I'm now (given the
On 5/1/19 10:15 AM, Francisco Olarte wrote:
Chuck:
On Wed, May 1, 2019 at 6:56 PM Chuck Martin wrote:
Thanks, guys. It should have been obvious to me, but wasn't.
I found the correct result was returned with either
AND event.DateTime <= 'May-1-2019 24:00'
or
AND event.DateTime::date <=
Thanks for the extra information. It is indeed an indexed column. I'll have
to think some more about how to address this in a general way, as this
issue can come up all over. I suppose using
AND datetime <= 'May 1, 2019 24:00'
would produce the same as
AND datetime < 'May 2, 2019'
wouldn't it?
Chuck:
On Wed, May 1, 2019 at 6:56 PM Chuck Martin wrote:
> Thanks, guys. It should have been obvious to me, but wasn't.
> I found the correct result was returned with either
> AND event.DateTime <= 'May-1-2019 24:00'
> or
> AND event.DateTime::date <= 'May-1-2019'
> The latter seems best.
The
On 5/1/19 11:39 AM, Julien Rouhaud wrote:
On Wed, May 1, 2019 at 6:27 PM Chuck Martin wrote:
I need help figuring out why a query is not returning the records I expect it
to. I'm searching on a DateTime column (timestamp without time zone - not
nullable). The query includes:
AND
Thanks, guys. It should have been obvious to me, but wasn't.
I found the correct result was returned with either
AND event.DateTime <= 'May-1-2019 24:00'
or
AND event.DateTime::date <= 'May-1-2019'
The latter seems best.
Chuck Martin
Avondale Software
On Wed, May 1, 2019 at 12:41 PM Tom
Chuck Martin writes:
> I need help figuring out why a query is not returning the records I expect
> it to. I'm searching on a DateTime column (timestamp without time zone -
> not nullable). The query includes:
> AND event.Primaryresp_fkey = 511 AND event.DateTime <= 'May-1-2019'
> AND
On Wed, May 1, 2019 at 9:27 AM Chuck Martin
wrote:
> I need help figuring out why a query is not returning the records I expect
> it to. I'm searching on a DateTime column (timestamp without time zone -
> not nullable). The query includes:
>
> AND event.Primaryresp_fkey = 511 AND
On Wed, May 1, 2019 at 6:27 PM Chuck Martin wrote:
>
> I need help figuring out why a query is not returning the records I expect it
> to. I'm searching on a DateTime column (timestamp without time zone - not
> nullable). The query includes:
>
> AND event.Primaryresp_fkey = 511 AND
I need help figuring out why a query is not returning the records I expect
it to. I'm searching on a DateTime column (timestamp without time zone -
not nullable). The query includes:
AND event.Primaryresp_fkey = 511 AND event.DateTime <= 'May-1-2019'
AND event.EventDone < 1
This does not
Thanks Stephen. Something for me to consider.
Charlin
On Wed, May 1, 2019 at 9:25 AM Stephen Frost wrote:
> Greetings,
>
> * Charlin Barak (charlinba...@gmail.com) wrote:
> > When migrating from Oracle number(10,3) to PostgreSQL, is numeric(10,3)
> > ideal or should I consider some other data
Greetings,
* Charlin Barak (charlinba...@gmail.com) wrote:
> When migrating from Oracle number(10,3) to PostgreSQL, is numeric(10,3)
> ideal or should I consider some other data types?
This really depends on what data is actually in that field and if you
need it to be exact.
If the field
Hi,
When migrating from Oracle number(10,3) to PostgreSQL, is numeric(10,3)
ideal or should I consider some other data types?
Thanks.
Charlin
35 matches
Mail list logo
