I have the following query:
SELECT *
FROM polygons
WHERE zoomlevel <= {zoom} AND st_intersects(way,{tileboundary})
For any given tile according to the openstreetmap tiles.
So zoomlevel is from 0..14 and the number of polygons in each level is roughly
exponential.
Postgres doc (https://www.postgre
Hi,
I'm stumbling on an issue which seems like this one:
https://www.postgresql.org/message-id/20170719152038.19353.71475%40wrigleys.postgresql.org,
but I hope someone can shed some light on my specific case.
Software:
POSTGIS="3.1.4 ded6c34" [EXTENSION] PGSQL="140" GEOS="3.8.0-CAPI-1.13.1 "
PROJ
Thanks, works perfectly!
On Sun, Jan 23, 2022 at 4:22 PM Tom Lane wrote:
> Paul van der Linden writes:
> > Thanks for the clarification, but giving up performance is a no-go for
> us.
> > Also I have my concerns about shemaqualifying each and every use of the
> ->
aul
On Thu, Jan 20, 2022 at 3:05 PM Tom Lane wrote:
> Paul van der Linden writes:
> > during maintenance I saw a lot of lines in my postgreslog saying:
> > CONTEXT: SQL function "line_function" during inlining
> > automatic analyze of table "osm.planet_
Hi,
during maintenance I saw a lot of lines in my postgreslog saying:
CONTEXT: SQL function "line_function" during inlining
automatic analyze of table "osm.planet_osm_line"
ERROR: operator does not exist: public.hstore -> unknown at character 45
HINT: No operator matches the given name
This one quite nicely explains it:
https://stackoverflow.com/questions/14897816/how-can-i-prevent-postgres-from-inlining-a-subquery
On Wed, Dec 8, 2021 at 3:14 AM David G. Johnston
wrote:
> On Tue, Dec 7, 2021 at 6:40 PM Дмитрий Иванов
> wrote:
>
>> I beg your pardon.
>> The problem is more or
It did indeed work as expected.
Took the query down from over 18 hours to 20 minutes, so a huge win!
Paul
On Thu, Dec 2, 2021 at 11:34 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Thursday, December 2, 2021, Paul van der Linden <
> paul.doskabou...@gmail.com&
Thanks a lot, completely forgot that one!
Gonna test that tomorrow...
On Thu, Dec 2, 2021 at 11:34 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Thursday, December 2, 2021, Paul van der Linden <
> paul.doskabou...@gmail.com> wrote:
>
>> Hi,
>>
Hi,
when switching to postgres 14 (from 11) I'm having some slow queries
because of inlining of CTE's.
I know I can get the same result as with PG11 when adding MATERIALIZED to
the cte, but the same application also needs to be able to run on older
postgres versions, so that is a no-go.
Is there a
nes
wrote:
> Why not create a table with cols a, b, c and d. Where you insert a row for
> each combination and key and index abc then return d?
>
> ons. 24. feb. 2021, 21:15 skrev Paul van der Linden <
> paul.doskabou...@gmail.com>:
>
>> Thanks for all the suggestions,
Thanks for all the suggestions,
When the server is not in use for mission-critical work, I'll definitely
going to do some testing based on your ideas.
Will let you know what comes out of that
Cheers,
Paul
On Thu, Feb 18, 2021 at 6:49 PM hubert depesz lubaczewski
wrote:
> On Thu, Feb 18, 2021 a
, Feb 16, 2021 at 07:30:23PM +0100, Paul van der Linden wrote:
> > Hi,
> > I have 2 functions:
> > CREATE FUNCTION foo(a text, b text, c text) RETURNS text AS
> > $func$
> > DECLARE
> > retVal text;
> > BEGIN
> > SELECT
> > CASE
&
Well, first off it's annoying if I have to change the function and a
reindex afterwards, and secondly, lots of other queries are blocking on
that reindex query (basically everything needing a queryplan on that table).
Materializing is also an option but that too is taking its time.
As far as I kn
Hi,
I have 2 functions:
CREATE FUNCTION foo(a text, b text, c text) RETURNS text AS
$func$
DECLARE
retVal text;
BEGIN
SELECT
CASE
WHEN a='v1' AND b='b1' THEN 'r1'
WHEN a='v1' THEN 'r2'
... snip long list containing various tests on a,b and c
WHEN a='v5
y (especially with nested cases)
On Fri, Jun 5, 2020 at 9:02 PM Tom Lane wrote:
> Paul van der Linden writes:
> > For the case where it isn't known if the case expression itself is
> indexed,
> > technically that should be added as a decision-node in the query planner.
n Fri, Jun 5, 2020 at 4:31 PM Tom Lane wrote:
> David Rowley writes:
> > On Fri, 5 Jun 2020 at 14:41, Paul van der Linden
> > wrote:
> >> If I have a query like:
> >>
> >> SELECT * FROM (
> >> SELECT
> >> CASE
> >> WHEN field
Hi,
Don't know if this already came up earlier but I have an idea for
improvement.
If I have a query like:
SELECT * FROM (
SELECT
CASE
WHEN field='value1' THEN 1
WHEN field='value2' THEN 2
END AS category
FROM table1
) AS foo
WHERE category=1
doesn't use the index on field, whil
I did it in pgadmin, without begin commit.
On Sat, Apr 13, 2019 at 4:24 PM Adrian Klaver
wrote:
> On 4/13/19 7:10 AM, Paul van der Linden wrote:
> > It was just 99 files of 1GB each for each id, and no I didn't vacuum.
> > I did see disk usage dropping quite a lot after d
ng to were
indeed deleted somehow (don't have an autovacuum running).
So not sure how or why, but my problem is solved
On Sat, Apr 13, 2019 at 2:06 AM Adrian Klaver
wrote:
> On 4/12/19 1:11 PM, Paul van der Linden wrote:
> > Hi,
> >
> > For my process, I needed to drop
Hi,
For my process, I needed to drop all the tables in a tablespace except one
which I truncated.
After that I would have expected to have a couple of KB max in that folder,
but there was about 200GB in it.
There were 2 sets of files (, .1 .. .99, and the same for
id2).
Tried the various options
20 matches
Mail list logo
